% TODO : 
% \begin{itemize} \item AJOUTER : un schema pour chaque geometrie d overlay structure 
% \item AJOUTER : ce qui apparait ci dessous
% \item !!!!!!!!!!!!!! HOMOGENEISER !!!!!!!!!!!!!!!!!!! famille/posnet
% \end{itemize}
% % 
% {******************A PLACER ?*********************}
% Mercury] est un r\'eseau overlay structur\'e capable de g\'erer des
%   requ\^etes par intervalles sur des donn\'ees multidimensionnelles. Dans
%   Mercury, une donn\'ee est repr\'esent\'ee comme un sous ensemble de couples
%   attribut-valeur. Une requ\^ete est consid\'er\'ee comme une conjonction de
%   pr\'edicats unaires. Mercury r\'esoud une requ\^ete en choisissant un
%   pr\'edicat et en routant de mani\`ere unidimensionnelle selon l'attribut sur
%   lequel porte ce pr\'edicat. Pour ce faire, \`a chaque attribut du sch\'ema
%   applicatif est associ\'e un sous-r\'eseau logique structur\'e en anneau. Une
%   donn\'ee est r\'ef\'erenc\'ee pour chacun de ses attributs sur l'anneau
%   associ\'e. Contrairement \`a dans Chord, le placement des donn\'ees se fait
%   selon l'ordre naturel et non une valeur de hachage. En cons\'equent, chaque
%   n\oe ud d'un anneau g\`ere une partition du domaine de d\'efinition d'un
%   attribut. Par suite, une requ\^ete est r\'esolue par tous les n\oe uds de
%   l'anneau associ\'e \`a l'attribut $a$, responsables pour les valeurs
%   satisfaisant les pr\'edicats s'appliquant \`a $a$. Pour optimiser le
%   routage, les auteurs ajoutent des liens longs pour rendre leur topologie  
%   petit-monde  , grace \`a une approximation de la densit\'e des n\oe uds d'un
%   anneau. De plus, le choix du l'anneau est optimis\'e en choisissant un
%   attribut non pas al\'eatoirement mais en fonction de son caract\`ere
%   discriminant (limitant le nombre de r\'eponses). Pour conclure sur Mercury,
%   on peut observe que l'approche multidimensionnelle expos\'ee consiste
%   essentiellement \`a r\'eduire d'une dimension l'espace de recherche.
%   Ajout\'e \`a la d\'emultiplication des \textit{hubs}, le passage \`a
%   l'\'echelle en termes de dimensionnalit\'e est compromis. La m\^eme remarque
%   vaut pour le passage \`a l'\'echelle en nombre de n\oe uds. En effet,
%   l'efficacit\'e du routage repose en grande partie sur le choix d'un attribut
%   au r\^ole discriminant, ce qui implique non seulement l'existence d'un tel
%   attribut, mais aussi la connaissance globale de la distribution des
%   donn\'ees sur l'anneau. 
% -----------------\\

% ---------------- \\
% Rationale pour choix du P2P : dispense utilisateur du recours \`a un serveur   back-end   co\^uteux (typiquement
% utilis\'e pour des t\^aches complexes) + co\^uts d'administration
% significativement r\'eduits.
% 
% {****************** ELIMINE *********************}
% P-grid [aberer03p-grid], 
\chapter{Indexation et localisation dans les syst\`emes distribu\'es \`a grande \'echelle} \label{chap:Indexation et localisation dans les syst\`emes distribu\'es \`a grande \'echelle}
\minitoc
%\ochap{}{}

%Les besoins applicatifs en termes d'indexation et de localisation de donn\'ees dans un syst\`eme, peuvent se d\'ecrire en termes de mod\`ele de donn\'ees et 
%de mod\`ele de requ\^etes support\'es par cette solution : quel type de donn\'ee est indexable ? quel type de requ\^ete est ex\'ecutable ? 

%Tandis que les capacit\'es de stockage de ces syst\`emes ne cessent de cro\^itre
%(TODO trouver ex. chiffr\'e), ces syst\`emes sont inutilisables en l'absence d'outils de recherche, 
%permettant aux utilisateurs d'acc\'eder efficacement aux donn\'ees pertinentes pour eux. 

%Ce chapitre a pour objectif de situer les apports de PosNet par rapport \`a l'\'etat de l'art des index d\'ecentralis\'es. ???? 

%Les solutions de gestion de donn\'ees peuvent \^etre compar\'ees selon les mod\`eles de donn\'ees et de requ\^etes support\'es.  
%Quel type de donn\'ee est indexable ? Quels types de requ\^ete est ex\'ecutable ?  

\ochap{C}{e} chapitre poursuit trois objectifs : (i) d\'efinir les concepts et la terminologie employ\'es dans cette th\`ese, (ii) 
faire un \'etat de l'art des m\'ecanismes d'indexation et de localisation, iii) d\'eterminer dans quelle mesure les solutions
d'index existantes satisfont les besoins \'enonc\'es dans le chapitre pr\'ec\'edent. 

En pr\'eliminaire \`a l'\'etat de l'art, nous pr\'esentons en \ref{sec:Mod\`eles d'index} les concepts qui sont utilis\'es dans les mod\`eles d'index. 
 %mod\`eles de requ\^etes et de mod\`ele de donn\'ees y sont essentielles : ce sont ces mod\`eles qui g\'en\'eralement motivent le choix d'une solution d'index. 
% : repr\'esentation des donn\'ees et taxonomie des types de requ\^etes notamment. 
Puis nous sp\'ecifions en \ref{sec:Grille d'\'evaluation ad hoc} les crit\`eres d'\'evaluation qui composent notre grille de lecture des solutions \`a l'\'etude. 
%circonscrirent les propri\'et\'es des solutions d'index distribu\'es au regard de notre probl\`ematique (cf. chapitre pr`'ec\'edent). 
Les notations introduites tout au long de ces deux sections servent de cadre de r\'ef\'erence dans la suite pour la description 
des solutions d'index. 
Nous parcourons en \ref{sec:Etat de l'art : en-dehors de l'approche P2P} des approches issues d'autres domaines ou appliquant d'autres techniques que le P2P, pour traiter des probl\'ematiques de recherche 
associ\'ees \`a la localisation de donn\'ees dans les syst\`emes distribu\'es de partage de donn\'ees. 
%Rapport\'es aux objectifs d\'ecrits dans l'introduction ainsi qu'aux crit\`eres d\'evaluation, 
L'approche P2P est introduite en \ref{sec:Pr\'eliminaires sur l'approche P2P pour la conception d'index d\'ecentralis\'es}.  
Les sections \ref{sec:Etat de l'art : Conception dirig\'ee par le routage d'overlays P2P structur\'es} et \ref{sec:Etat de l'art : Conception dirig\'ee par les donn\'ees d'overlays P2P structur\'es} d\'etaillent les travaux P2P comparables \`a PosNet, la solution propos\'ee dans cette th\`ese. 
La pertinence des solutions d'index rencontr\'ees est \'evalu\'ee en appliquant les crit\`eres postul\'es en d\'ebut de chapitre. 
% Ce chapitre aboutit \`a la d\'efinition, par rapport aux objectifs affich\'es, d'un ensemble de limitations de l'existant et 
% sert de pr\'eliminaire \`a la sp\'ecification de notre probl\'ematique. 
 
%Ce qui nous permet finalement de circonscrire, section \ref{problematique-contributions} un ensemble de limitations de l'existant
%qui constitue le champ de notre probl\'ematique. 
%Cette probl\'ematique dicte les contributions de la solution que nous apportons : PosNet.

% \section{Mod\`eles de r\'eseau}\label{modeles}
% TODO

\section{Mod\`eles d'index} \label{sec:Mod\`eles d'index}
Nous commen\c cons par d\'efinir un \emph{index distribu\'e}.
%'ex\'ecution sur ces donn\'ees de requ\^etes de recherche. 
% Soit un ensemble $S$ de donn\'ees. Chaque donn\'ee de $S$ est un $n$-uplet $(v_o,v_1,\ldots,v_n-1)$ de valeurs qui sont les attributs de la donn\'ee. La localisation de donn\'ees 
% dans $S$ est d\'eclench\'ee par une requ\^ete. Une requ\^ete de localisation (en l'absence d'ambiguit\'e on parlera simplement de requ\^ete) 
% sp\'ecifie des conditions que doivent satisfaire les attributs des donn\'ees recherch\'ees. Un syst\`eme d'indexation et de localisation, appel\'e encore index, a pour r\^ole de 
% stocker un ensemble $S$ et d'ex\'ecuter une recherche sur r\'eception d'une requ\^ete. Si les conditions de la requ\^ete porte sur plus d'un attribut simultan\'ement, 
% alors l'index est consid\'er\'e multidimensionnel (dans le cas contraire, on parle d'index unidimensionnel). 
Le r\^ole d'un index distribu\'e est de permettre aux utilisateurs d'un syst\`eme distribu\'e 
d'acc\'eder \`a des ressources dont ils ont besoin et ce, de mani\`ere transparente, quelque soit la localisation de ces donn\'ees. 
%Le r\^ole d'un index est de permettre l'extraction de donn\'ees efficace \`a grande \'echelle.  
%Le r\^ole d'un index est d'indexer les donn\'ees pour permettre leur extraction selon des crit\`eres.
Ces ressources peuvent \^etre de tous types : ressources machine, services, \ldots Un exemple d'usage courant est l'indexation de fichiers : fichiers musicaux, images, pages Web, etc. Dans la suite du document, nous employons le terme g\'en\'erique \emph{donn\'ees} pour d\'esigner les objets de recherche. 

La structure d'index\footnote{Le terme d'index est polys\'emique : il d\'esigne selon le contexte ou bien un syst\`eme de stockage 
et de localisation de donn\'ees ou bien la structure de donn\'ees sous-jacente \`a un tel syst\`eme. 
En cas d'ambiguit\'e, nous distinguons les deux sens en employant les termes d'index pour d\'esigner le syst\`eme, 
et structure d'index pour la structure de donn\'ees.} est construite \`a partir des donn\'ees ins\'er\'ees.
L'extraction de donn\'ees est d\'eclench\'ee par une requ\^ete, dont les conditions permettent d'op\'erer une s\'election parmi les donn\'ees (nous employons indiff\'eremment les termes d'extraction, de localisation et de recherche). 

\begin{floatingfigure}[option]{8cm}
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.3\textwidth]{fig/indexFonctionnementGeneral}
		\caption{Fonctionnement g\'en\'eral d'un index distribu\'e : interaction entre un utilisateur et le syst\`eme.}
\label{fig:fonctionnementIndex}
\end{floatingfigure}

%sp\'ecifie les conditions que doivent satisfaire les donn\'ees.  
%Un syst\`eme d'indexation et de localisation, appel\'e encore index, a pour r\^ole de stocker un ensemble $S$ et d'ex\'ecuter une recherche sur r\'eception d'une requ\^ete. 
La grammaire des requ\^etes d\'epend des donn\'ees acc\'ed\'ees. Par exemple, dans un index de fichiers, les requ\^etes
peuvent porter sur des mots cl\'es, par le biais d'expressions r\'eguli\`eres.  
% Si les conditions de la requ\^ete portent sur plus d'un attribut simultan\'ement, alors l'index est consid\'er\'e multidimensionnel 
% (dans le cas contraire, on parle d'index unidimensionnel). 
% Si les donn\'ees sont dispers\'ees sur un ensemble de serveurs, alors l'index est distribu\'e. Si la structure de donn\'ee d'index et les 
% algorithmes la manipulant sont \'egalement distribu\'es, alors l'index est d\'ecentralis\'e. Nous nous int\'eressons plus particuli\`erement \`a cette derni\`ere cat\'egorie d'index dans cette th\`ese.  
Le fonctionnement g\'en\'erique d'un index est illustr\'e par la figure \ref{fig:fonctionnementIndex} : un utilisateur envoie la description d'une donn\'ee $\Phi(\Delta)$ et re\c coit la donn\'ee 
$\Delta$. 

% \begin{floatingfigure}[option]{8cm}%[!h]%
% 	\centering
% 	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
% 		\includegraphics[width=0.40\textwidth]{fig/CouchesBoiteNoirePosNet}
% 		\caption{TODO effacer tous les termes et mettre : Index, donn\'ees brutes, serveurs + relier serveurs en r\'eseau /// Architecture en couches d'un index distribu\'e, repr\'esentation en bo\^ite noire de l'index}
% \label{fig:indexboitenoire}
% \end{floatingfigure}


Le syst\`eme est distribu\'e sur un r\'eseau de serveurs. Chaque serveur peut ou bien stocker des donn\'ees, ou bien participer 
\`a leur indexation et localisation, ou bien les deux. 
Dans un contexte d\'ecentralis\'e, les donn\'ees et les traitements sont distribu\'es, aucun n\oe ud du r\'eseau n'ayant une vue globale du syst\`eme. 
La figure \ref{fig:indexboitenoire} pr\'esente une vue abstraite d'un index distribu\'e, sous la forme d'une couche logicielle 
interm\'ediaire entre les donn\'ees et les serveurs qui les h\'ebergent.
%Le choix d'un index est orient\'e en tout premier lieu par le type de donn\'ees que l'on souhaite index\'er et le type de requ\^etes que l'on souhaite ex\'ecuter dessus.  
% \begin{figure}[!h]
% 	\centering
% 	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
% 		\includegraphics[width=7cm]{fig/indexFonctionnementGeneral.jpg}
% 		\caption{Fonctionnement g\'en\'eral d'un index distribu\'e : interaction entre un utilisateur et le syst\`eme.}
% 	\label{fig:fonctionnementIndex}
% \end{figure}

\begin{figure}[!h]%[option]{8cm}
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.45\textwidth]{fig/CouchesBoiteNoirePosNet}
		\caption{TODO effacer tous les termes et mettre : Index, donn\'ees brutes, serveurs + relier serveurs en r\'eseau /// Architecture en couches d'un index distribu\'e, repr\'esentation en bo\^ite noire de l'index}
\label{fig:indexboitenoire}
\end{figure}

Bri\`evement, on peut distinguer les diff\'erentes solutions d'index
selon (i) le type de donn\'ees trait\'e : structur\'e (donn\'ees relationnelles, objet, etc.) ou semi-structur\'e (HTML, XML, graphes, etc.)
 ou bien non-structur\'e (texte, images, son, etc.) ; (ii) le type de requ\^etes trait\'e. Les deux
facteurs sont d\'ependants. Traditionnellement, les donn\'ees structur\'ees sont interrog\'ees par le biais de requ\^etes de type relationnel, au sein
de syst\`emes de bases de donn\'ees (relationnelles). Les donn\'ees non-struc\-tur\'ees, elles, sont interrog\'ees par le biais de requ\^etes
exactes ou de requ\^etes de similarit\'e au sein de syst\`emes de recherche d'information.

Nous nous limitons dans cette th\`ese en traitant les donn\'ees structur\'ees. Nous pr\'esentons dans la suite le type de donn\'ees et les types de requ\^etes. La formalisation du mod\`ele de donn\'ees sp\'ecifique \`a PosNet est donn\'ee au chapitre \ref{chap:Probl\'ematiques et pr\'esentation g\'en\'erale de PosNet}. 

% Dans la suite du document, nous utilisons indiff\'eremment pour :
% \begin{itemize}
% 	\item index : syst\`eme d'indexation et de localisation, annuaire, centre de donn\'ees (pour \emph{data store}) ;
% 	\item donn\'ee : ressource, objet, information ; 
% 	%\item attribut (multi-attributs, mono-attribut) : dimension (multidimensionnelles, unidimensionnelle) ;
% 	\item localisation : recherche, d\'ecouverte, extraction ;
% \end{itemize}

% \begin{tabular}{|l|c|c|}
% \hline
% Terme & Usage & Synonymes  \\
% \hline
% \hline
% Index & - & Syst\`eme d'indexation et de \\
% & & localisation, annuaire, centre \\
% & & de donn\'ees (pour \emph{data store}) \\
% \hline
% Donn\'ee & - & - \\
% \hline
% Attribut & - & - \\
% \hline
% Dimension & Domaine de d\'efinition & - \\
%  & d'un attribut &  \\
% \hline
% Localisation & - & Recherche, d\'ecouverte, \\
% &  & extraction \\
% \hline
% \end{tabular} \\

\subsection{Mod\`ele de donn\'ees type} \label{sec:Mod\`ele de donn\'ees utilis\'e}
% La r\'esolution d'un probl\'eme par un automate n\'ecessite de repr\'esenter l'information sur le domaine trait\'e appel\'e parfois univers du discours 
% sous une forme digitale qui soit interpr\'etable et manipulable par un ordinateur. 
% Le mod\'ele doit donc \^etre sp\'ecifi\'e en utilisant des donn\'ees cod\'ees et stock\'ees en m\'emoire ainsi que par des op\'erations (programmes) 
% qui d\'eterminent comment ces donn\'ees peuvent \^etre utilis\'ees pour r\'esoudre le probl\`eme pos\'e [Diettrich94???]. Un mod\`ele peut se d\'efinir comme une 
% repr\'esentation abstraite de l'information et \'eventuellement des op\'erateurs de manipulation de l'information.]
Un mod\`ele de donn\'ees est une repr\'esentation logique des donn\'ees, s\'epar\'ee de la repr\'esentation physique, 
et permettant le traitement automatique des donn\'ees. 
%La distinction entre $\mathcal{O}$ et $\mathcal{S}$ permet de s\'eparer la repr\'esentation physique de la repr\'esentation logique des objets de recherche. 
Dans le pr\'esent document, les donn\'ees sont 
typiquement repr\'esent\'ees selon un mod\`ele de type relationnel. 
%Il en existe de nombreux types (
%%mod\'ele relationnel ou sch\'ema de base de donn\'ees, %[REF]
%%diagramme de structure de donn\'ees, %([bachman69data])
%mod\`ele de donn\'ees s\'emantique, %([bekke92semantic])
%mod\`ele orient\'e-objet, 
%mod\`ele hi\'erarchique
%%mod\`ele Entit\'e-Relation, %([chen76entity])
%etc.).  
%Un mod\`ele de donn\'ees particulier parmi les mod\`eles de base de donn\'ees est 
%
%le fichier plat (\emph{flat file model}). 
%Dans un fichier plat, les donn\'ees sont organis\'ees 
%sous forme de tableau, en lignes et en colonnes. Chaque ligne correspond \`a une donn\'ee, chaque colonne \`a un attribut. 
Dans ce mod\`ele, une donn\'ee est d\'efinie par un ensemble d'\emph{attributs}. 
Le nombre d'attributs par donn\'ee est le m\^eme pour toutes les donn\'ees.  
Chaque attribut poss\`ede un type et est associ\'e \`a un domaine de valeurs, born\'e inf\'erieurement et sup\'erieurement. 
%On suppose sans perte de g\'en\'eralit\'e que les valeurs les plus \'elev\'ees sont pr\'ef\'erables. 

Plus formellement, soit un ensemble des donn\'ees brutes $\mathcal{O}$. On suppose l'existence d'une fonction $g$ 
qui \`a chaque donn\'ee $o_i$ de $\mathcal{O}$ fait correspondre une liste ordonn\'ee de $d$ valeurs d'attributs $s_j(o_i)$ $(1 \leq j \leq d)$.
Une interpr\'etation g\'eom\'etrique de l'image de l'ensemble $\mathcal{O}$ par $g$ est un ensemble de points dans un espace $\mathcal{S}$
nomm\'e \emph{espace des attributs}, dans lequel chaque axe correspond \`a un attribut $s_j$ (c'est donc un espace \`a $d$ dimensions). 
Une donn\'ee $o_i$ appartenant \`a $\mathcal{O}$ peut \^etre repr\'esent\'ee comme un point dans $\mathcal{S}$ : 
$g(o_i) = p = \{ p[1], \ldots,\ p[d]\}$, o\`u $p[j] = s_j(o_i)$ est une valeur de la dimension $d_j$. 
% $(p_1, p_2, \ldots, p_k)$. 
% Une interpr\'etation g\'eom\'etrique de l'ensemble des images de $\mathcal{U}$ par $g$ est un ensemble de points dans un espace 
% nomm\'e espace des attributs, dans lequel chaque axe $d_1,d_2,\ldots,d_k$ correspond \`a un attribut (c'est donc un espace \`a $k$ dimensions). 
% Une donn\'ee $v$ de $\mathcal{V}$ est repr\'esent\'ee comme un point $p$ dans cet espace des attributs : 
% $p = \{ p_1, p_2, \ldots, p_k \}$ o\`u $p_i$ est une valeur sur l'axe $d_i$. 
La figure \ref{fig:espaceAttributs} donne une repr\'esentation g\'eom\'etrique en deux dimensions de l'ensemble des donn\'ees brutes $\mathcal{O}$, 
de l'espace des attributs $\mathcal{S}$ et de l'image $g\langle \mathcal{O} \rangle$ des donn\'ees de $\mathcal{O}$.

%TODO adapter schema en faisant un patatoide pour les donnees brutes
%\begin{figure}[!h]
%	\centering
%	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
%		\includegraphics[width=8cm]{fig/ex_espace_solutions.png}
%		%\caption{Augmentation logarithmique du temps de r\'eponse $R_t$ en fonction de la taille du SGBD $GB_s$ et du volume des transactions $T_x$ (adapt\'e de http://www.codefutures.com/database-sharding/).}
%	%\label{fig:relationNbTransactionsTempsReponse}
%\end{figure}
\begin{figure}[!h]
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.7\textwidth]{fig/espaceAttributs_vlachou.jpg}
	%	\caption{Repr\'esentation g\'eom\'etrique en deux dimensions de l'ensemble des donn\'ees brutes $\mathcal{O}$, de l'espace des 	attributs $\mathcal{S}$ et de l'image $g\langle \mathcal{O} \rangle$ des donn\'ees de $\mathcal{O}$.}

\caption{TODO rajouter des fleches /// Transformation de l'ensemble des donn\'ees brutes en un ensemble de points dans un espace des attributs}

	\label{fig:espaceAttributs}
\end{figure}

L'ensemble $g\langle \mathcal{O} \rangle$ constitue l'ensemble des donn\'ees manipul\'ees par l'index. 
% Les distributions de $g\langle \mathcal{O} \rangle$ g\'en\'eralement rencontr\'ees dans la litt\'erature sont ou bien uniforme 
% (l'espace des solutions est peupl\'e de mani\`ere homog\`ene) ou bien
% non-uniforme (l'espace des solutions pr\'esente des concentrations de points en certains endroits). 

% La distribution des donn\'ees est li\'ee \`a la probl\'ematique
% de l'\'equilibrage de charge au sein de l'index, comme expos\'e dans la suite de ce chapitre, section \ref{}). 

Le tableau \ref{fig:espaceAttributs} r\'ecapitule les symboles qui seront repris tout au long du document. \\

\begin{tabular}{|l|c|}
\hline
Symbole & Description\\
\hline
\hline
$\mathcal{O}$ & L'ensemble des donn\'ees brutes\\
\hline
$\mathcal{S}$ & L'espace de repr\'esentation des donn\'ees ou espace des attributs\\
\hline
$\mathcal{N}$ & L'espace des serveurs \\
\hline
$\mathcal{V}$ & L'espace de repr\'esentation des serveurs ou espace des n\oe uds\\
\hline
$d$ & Le nombre de dimensions de l'espace des attributs\\
\hline
$d_i$ & La $i$-\`eme dimension de l'espace des attributs\\
\hline
$s_j(o_i)$ & L'attribut $j$ du point de l'espace des attributs repr\'esentant l'objet $o_i$\\
\hline
$p[j]$ & La projection du point $p$ sur l'axe $d_j$ de l'espace des attributs\\
\hline
% $\mathcal{N}$ & L'ensemble des n\oe uds du r\'eseau physique
% \hline 
% $\mathcal{???}$ & L'espace de repr\'esentation des n\oe uds
% \hline 
$g$ & L'application de $\mathcal{O}$ en $\mathcal{S}$\\
\hline
$N$ & Le nombre de n\oe uds de r\'eseau\\
\hline


% $f$ & L'application de $\mathcal{N}$ en $\mathcal{???}$
% \hline
% $N$ & Cardinalit\'e de $\mathcal{???}$
% \hline
\end{tabular}
\captionof{table}{Tableau r\'ecapitulatif des symboles}
\label{TODO a deplacer /// Tableau r\'ecapitulatif des symboles}
\vspace{0.6cm}

% Dans la discussion qui suit, nous supposons que des syst\`emes \`a $N$ n\oe uds, avec des identifiants sur log $N$ bits ( 
% m\^eme si en pratique, les algorithmes utilisent typiquement des identifiants sur log $N'$ bits, avec $N'  >> N$, de telle sorte \`a ce que l'espace 
% des identifiants ne soit pas totalement peupl\'e). 
% Enfin, par abus de langage nous employons dans la suite du document les termes <<  donn\'ee >> et << n\oe ud  >> dans le sens de leur repr\'esentation dans un espace de nommage. 

\subsection{Mod\`ele de requ\^etes type} \label{subsec:Mod\`ele de requ\^etes de recherche}
%Nous parlons indiff\'eremment dans le pr\'esent document de requ\^etes ou de recherches. 
Dans le cas de recherches sur le contenu, les requ\^etes servent \`a effectuer des s\'elections de points dans l'espace des attributs.
% ", les s\'elections sont formul\'ees selon des req\^etes exactes, dans lesquelles la valeur exacte de chaque attribut 
% est sp\'cifi\'ee, ou bien des requ\^etes par plages de valeurs, qui sp\'ecifient pour chaque attribut un intervalle de valeurs.  
Nous consid\'erons deux classes de requ\^etes : les \emph{requ\^etes de satisfaction} et les \emph{requ\^etes de comparaison\footnote{La terminologie est propre \`a ce document, 
faute d'\^etre standardis\'ee. Il est possible de faire l'analogie entre ces classes de requ\^etes et le domaine de la programmation math\'ematique, qui cherche 
\`a r\'esoudre des probl\`emes d'optimisation sous contraintes (dans notre cas, les probl\`emes sont s\'epar\'es : fonction \`a optimiser ou contraintes de satisfaction).}}. 
Dans les d\'efinitions qui suivent, les exemples 
%sont inspir\'es de l'\'etude de cas vue en introduction, 
d\'ecrivent le cas d'une plateforme de t\'el\'echargement de fichiers indexant des morceaux de musique selon 5 attributs possibles : 
(l'artiste, le titre du morceau, la date de sortie du morceau, le nombre de fois o\`u il a \'et\'e t\'el\'echarg\'e, la taille). 
%Pour des raisons de clart\'e nous omettons certains attributs qui ne sont pas pertinents dans le cadre de la requ\^ete. 
%\paragraph{}De mani\`ere g\'en\'erale, \`a chaque type de requ\^ete correspond un type d'algorithme de r\'esolution.

Suivant la terminologie employ\'ee par Risson et Moors \cite{risson06survey}, il nous arrivera dans la suite du document de d\'esigner par \emph{index s\'emantique}, 
les index supportant des recherches sur le contenu (par opposition aux index ne supportant que les recherches exactes). 


\paragraph{Requ\^etes unidimensionnelles et multidimensionnelles}
%Nous rappelons ici la d\'efinition des requ\^etes unidimensionnelles et multidimensionnelles donn\'ee plus haut. 
Si les conditions de la requ\^ete portent sur plus d'un attribut simultan\'ement, alors l'index est consid\'er\'e multidimensionnel. 
Dans le cas contraire, on parle d'index unidimensionnel. 

% $\blacktriangleright${Exemple} d'utilit\'e des requ\^etes multidimensionnelles : \\
% \begin{boitenumeroteeavecunedoublebarre}{}
% Alexandra d\'esire retrouver un morceau dont le titre contient le mot "blue". 
% Dans le cas d'une plateforme bas\'ee sur un index cl\'e-valeur, l'interface de recherche est limit\'e \`a un 
% champ de saisie. Elle entre donc le mot cl\'e "blue" et l'index retourne la totalit\'e 
% des morceaux dont la description contient ce mot cl\'e : non seulement dans le titre, mais aussi 
% dans le nom de l'interpr\`ete, dans le nom du label, etc. 
% \end{boitenumeroteeavecunedoublebarre}

$\blacktriangleright${Exemple} d'utilit\'e des requ\^etes multidimensionnelles : 
\bkcountfalse
\begin{breakbox}
Alexandra d\'esire retrouver un morceau dont le titre contient le mot << blue  >>. 
Dans le cas d'une plateforme bas\'ee sur un index cl\'e-valeur, l'interface de recherche est limit\'ee \`a un 
champ de saisie. Elle entre donc le mot cl\'e << blue >> et l'index retourne la totalit\'e 
des morceaux dont la description contient ce mot cl\'e : non seulement dans le titre, mais aussi 
dans le nom de l'interpr\`ete, dans le nom du label, etc. 
Une indexation multi-attributs aurait permis de distinguer entre les attributs et de ne retourner que les fichiers dont 
le titre du morceau contient << blue >>, augmentant d'autant la pr\'ecision de la recherche.  
\end{breakbox}

\paragraph{Requ\^etes de satisfaction}
Il s'agit de la classe de requ\^etes la plus fr\'equemment support\'ee par les solutions d'index P2P. 
Dans ce mod\`ele, une requ\^ete est une conjonction de pr\'edicats. 
Chaque pr\'edicat porte sur un attribut et exprime une condition que doit satisfaire cet
attribut : << est \'egal \`a >>, << est inf\'erieur \`a et sup\'erieur \`a >>, etc.
Une interpr\'etation g\'eom\'etrique d'un pr\'edicat est une r\'egion de l'espace des attributs 
(r\'egion contenant l'ensemble des points satisfaisant le pr\'edicat en question). 
Une conjonction de $d$ pr\'edicats d\'efinit donc une r\'egion $U$ qui est l'intersection de $d$ r\'egions de l'espace des attributs. 
L'ensemble des solutions retourn\'e par une requ\^ete de satisfaction portant sur $d$ attributs 
est donc l'ensemble des donn\'ees telles que leur image appartient \`a $U$. La figure \ref{fig:conjonctionPredicats} 
donne une repr\'esentation g\'eom\'etrique en deux dimensions de l'ensemble $U$ des points de $\mathcal{S}$ satisfaisant la conjonction de pr\'edicats
$(p[1] \leq s_1 \leq q[1]) \wedge (p[2] \leq s_2 \leq q[2])$. L'ensemble des solutions est obtenu en intersectant $U$ et 
$g \langle \mathcal{O} \rangle$, soit l'ensemble $\{o \in \mathcal{O} | g(o) \in U\}$

\begin{figure}[!h]
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=8cm]{fig/conjonctionPredicats_vlachou.jpg}
		\caption{TODO placer p et q et q[2] /// Repr\'esentation g\'eom\'etrique en deux dimensions de l'ensemble $U$ des points satisfaisant une conjonction de pr\'edicats}
	\label{fig:conjonctionPredicats}
\end{figure}
%TODO schema montrant $\mathcal{U}$, avec 2 r\'egions, $U$ et $U \cap g\langle \mathcal{V} \rangle$\\

% En g\'en\'eral, une requ\^ete sp\'ecifie : i) un type (par ex. exacte ou par intervalle) ; ii) un objet. 
% Selon les types de requ\^etes, l'objet sp\'ecifi\'e est une r\'egion de l'espace 
% 
% Les objets manipul\'es dans les cas que nous envisageons sont des points (par opposition \`a des formes
% multidimensionnelles telles que des lignes, poly\`edres, etc.) dans univers
% des solutions discr\'etis\'es. 
Selon la terminologie employ\'ee dans \cite{gaede98multidimensional}, les types de requ\^etes de pr\'edicats typiquement rencontr\'es sont
les suivants. 
%Nous rappelons les attributs consid\'er\'es : l'artiste, le titre du morceau, la date de sortie du morceau, un indice de popularit\'e, un indice de qualit\'e. 

\begin{itemize}
%\item[~\textit{Requ\^ete~}\textit{exacte}] ~
\item[\textit{Requ\^ete exacte :}]
Les pr\'edicats sont des pr\'edicats d'\'egalit\'e. La conjonction de pr\'edicats d\'efinit donc un point unique $p$ dans l'espace des attributs. 
L'ensemble des solutions est $RE=\{o \in \mathcal{O} | g(o) = p \}$.
Typiquement, les recherches de mots-cl\'es et les recherches de cl\'e dans les tables de hachage, que nous d\'etaillons en \ref{subsec:Taxonomie g\'en\'erale des overlays P2P}, sont des recherches de type exact. 
%Les index ne supportant que les requ\^etes exactes sur les cl\'es peuvent \^etre consid\'er\'es comme offrant 
%les fonctionnalit\'es d'une table de hachage (API put(key, value), get(key). 
%La section \ref{subsec:Taxonomie g\'en\'erale des overlays P2P} leur est consacr\{ee. 

$\blacktriangleright${Exemple :}  
\bkcountfalse
\begin{breakbox}
Si l'on consid\`ere les trois attributs : artiste, titre et date, 
la requ\^ete de mots-cl\'es (artiste = << Ant\^onio Carlos Jobim >>, titre = << Agua de Beber >>, date = 1958) 
retourne le ou les fichiers correspondant \`a un morceau dont  
l'artiste est Ant\^onio Carlos Jobim, le titre << Agua de Beber >> et qui est sorti en 1958. 
\end{breakbox}
\vspace{0.6cm}
%\item[~\textit{Requ\^ete~}\textit{par~}\textit{plages~}\textit{de~}\textit{valeurs~}] ~
\item[\textit{Requ\^ete par intervalles (ou plages de valeurs) :}]
Un ou plusieurs pr\'edicats sont des pr\'edicats d'in\'egalit\'e. La conjonction de pr\'edicats d\'efinit donc un hyper-rectangle $h$ dans l'espace des attributs. 
L'ensemble des solutions est $RI=\{o \in \mathcal{O} | g(o) \in h \}$. 

$\blacktriangleright${Exemple :}  
\bkcountfalse
\begin{breakbox}
Si l'on consid\`ere les attributs artiste et date, 
La requ\^etes (artiste = << Ant\^onio Carlos Jobim >>, date > 1958) retourne tous les fichiers correspondant \`a des morceaux dont l'artiste est Ant\^onio Carlos Jobim et qui sont post\'erieurs \`a 1958.
\end{breakbox}
\vspace{0.6cm}
%\item[~\textit{Requ\^ete~}\textit{incompl\`ete~}\textit{ou~}\textit{partielle~}] ~
\item[\textit{Requ\^ete partielle :}]
  %\item[~\textit{Requ\^ete~incompl\`ete}~\textit{(Incomplete}~\textit{query)}~]
Un ou plusieurs pr\'edicats sont remplac\'es par des << jokers >> (\emph{wild cards}). 

$\blacktriangleright${Exemple :}  
\bkcountfalse
\begin{breakbox}
La requ\^ete (artiste = << Ant\^onio Carlos Jobim >>, *, 1958, *, *) retourne tous les fichiers correspondants \`a des morceaux dont l'artiste est 
Ant\^onio Carlos Jobim et qui sont sortis en 1958.
\end{breakbox}

\end{itemize}

\vspace{0.6cm}
La figure \ref{fig:requetesSatisfaction} met en regard les trois types de requ\^etes de satisfaction, dans un espace des attributs \`a deux dimensions : 
(a) les contraintes de la requ\^ete exacte $(s_1=p[1],s_2=p[2])$ sont v\'erifi\'ees par $p$ ; 
(b) les contraintes de la requ\^ete par plages de valeurs $(p[1] \leq  s_1 \leq q[1], p[2] \leq s_2 \leq q[2])$ sont v\'erifi\'ees par les points de l'hypercube $h$ ; 
(c) le contraintes de la requ\^ete partielle $(*, p[2] \leq s_2 \leq q[2])$ sont v\'erifi\'ees par la zone hachur\'ee.

\begin{figure}[!h]
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.9\textwidth]{fig/requetesSatisfaction.jpg}
		\caption{Illustration de requ\^etes de satisfaction dans un espace des attributs \`a deux dimensions}
	\label{fig:requetesSatisfaction}
\end{figure}

\paragraph{Requ\^etes de comparaison}
Les requ\^etes de satisfaction retournent des donn\'ees selon des crit\`eres << absolus >>. Autrement dit, ces crit\`eres portent sur les attributs, ind\'ependamment des valeurs d'attributs des autres donn\'ees index\'ees. 
Elles pr\'e-supposent une connaissance \emph{a priori} des donn\'ees que l'on recherche. 
Les requ\^etes de comparaison, a contrario, donnent une information sur la composition de l'ensemble des donn\'ees, en exploitant un ordre d\'efini sur ces donn\'ees. 
% Les requ\^etes de comparaison sont utiles dans une approche exploratoire des donn\'ees. Elle permettent la recherche des donn\'ees
% pr\'esentant les meilleurs compromis (dans le cas multidimensionnel, un optimum global n'existe pas forc\'ement), 
% la recherche des donn\'ees les plus pertinentes selon un crit\`ere donn\'e (et de limiter \'eventuellement le nombre de solutions retourn\'ees par une requ\^ete)
% ou encore la recherche de donn\'ees par similarit\'e (si une donn\'ee est pertinente, alors les donn\'ees similaires pr\'esentent de grandes chances de l'\^etre aussi). 
% Les requ\^etes de comparaison ont des champs d'application vari\'es (d\'ecision multi-crit\`eres, syst\`emes de monitoring, extraction d'information, bases de 
% donn\'ees multim\'edia, analyse de donn\'ees spatiales, etc.) et ont \'et\'e abondamment \'etudi\'ees dans les syst\`eme centralis\'es 
% (se reporter \`a \cite{papadias03optimal} pour une \'etude exhaustive)
%-----------
% (pour les requ\^etes top-k, par exemple, cf. \cite{akbarinia06reducing}
%, pour les requ\^etes kNN, cf. \cite{}, pour les requ\^etes skyline, cf. \cite{})
% Abkarinia \emph{\emph{\emph{et al.}}} soulignent dans \cite{akbarinia06reducing} la vari\'et\'e des champs d'application des requ\^etes top-$k$ et la quantit\'e subs\'equente de travaux publi\'es 
% sur le sujet dans les syst\`emes centralis\'es : syst\`emes de monitoring \cite{}, extraction d'information \cite{}, 
% bases de donn\'ees multim\'edia \cite{}, analyse de donn\'ees spatiales \cite{}, etc. 
Les requ\^etes de comparaison ont \'et\'e \'etudi\'ees plus r\'ecemment dans le domaine des index distribu\'es. 
Ci-dessous, les principales requ\^etes trait\'ees de ce type dans la litt\'erature P2P : 

\begin{itemize}

\item[\textit{Requ\^ete top-k :}]
%On efficient top-k query processing in highly distributed environments, vlachou08efficient POUR LE TAB RECAP DES NOTATIONS ET LE FORMALISME p[i]
Etant donn\'ee une fonction d'utilit\'e $f$ d\'efinie sur les attributs de $\mathcal{U}$, 
l'ensemble des solutions est compos\'e des $k$ donn\'ees de $\mathcal{V}$ dont les images par $g$ maximisent $f$ 
(selon l'ordre d\'efini sur les donn\'ees).
%(c'est-\`a-dire maximisent $f$ dans le cas, qui est le notre, o\`u les valeurs les plus \'elev\'ees sont pr\'ef\'er\'ees). 
% : $\{o \in \mathcal{O} | Max f(g(o)) \}$.  \\
%Le plus souvent, une fonction de d'agr\'egation monotone telle que si $\forall i, p[i] \leq p'[i]$ alors $f(p) = f(p[1], \ldots, p[d]) \leq f(p'[1], \ldots, p'[d) = f(p')$. 

$\blacktriangleright${Exemple :}  
\bkcountfalse
\begin{breakbox}
La requ\^ete ($k$ = 5, $f$ = popularit\'e) retourne les 5 morceaux les plus populaires. 
\end{breakbox}
\vspace{0.6cm}
\item[\textit{Requ\^ete k~plus~proches~voisins :}] 
Soient un point $q$ de l'espace des attributs, une fonction distance $f$ et un entier $k$ non nul. 
L'ensemble des solutions \`a une requ\^ete de k plus proches voisins\footnote{Requ\^ete de k plus proches voisins ou kNN pour << k Nearest Neighbours >>} de $q$ est compos\'e des $k$ donn\'ees $o$ de $\mathcal{O}$ dont les images $p$ par 
$g$ sont les plus proches de $q$ dans l'espace des attributs est, plus formellement : $(f(g(o),q)) = min_{1 \leq i \leq d}f(p[i],q)$. 
La fonction distance est habituellement d\'efinie en utilisant une distance de Minkowski : distance euclidienne ou de Manhattan, par exemple. \\
%Les requ\^etes de k plus proches voisins ou kNN (pour \emph{k Nearest Neighbours}) sont une g\'en\'eralisation des requ\^etes par similarit\'e ou NN.
$\blacktriangleright${Exemple :}  
\bkcountfalse
\begin{breakbox}
Eloignons-nous de notre exemple type pour consid\'erer une description alternative de fichiers de musique, laquelle carat\'eriserait le contenu musical du fichier 
: les \'el\'ements rythmiques, la tonalit\'e, les instruments jou\'es et leur distribution temporelle, etc. 
(pour un exemple d'une telle description, cf. \cite{tzanetakis02musical}). 
Une telle description permet de d\'efinir une distance $f$ entre deux morceaux 
de musique, autorisant des requ\^etes de la forme knn(5, $q$), qui retournent les 5 morceaux les plus musicalement similaires au morceau repr\'esent\'e par 
$q$\footnote{Pandora \cite{pandora} est un exemple de site Web ayant propos\'e ce type de service.}.
\end{breakbox}
\vspace{0.6cm}

\item[\textit{Requ\^ete de front de Pareto (ou skyline) :}]
Retourne les donn\'ees Pareto-optimales, c'est-\`a-dire les donn\'ees dont les images par $g$ ne sont domin\'ees par aucune autre solution.  
La pareto-dominance est d\'efinie formellement de la mani\`ere suivante. Etant donn\'ee $\prec_{i}$ une relation d'ordre d\'efinie sur la $i$-\`eme 
dimension d'un espace des attributs 
\`a $d$ dimensions, un point $p$ de l'espace domine $q$, ce qui s'\'ecrit $p \succ q$, si et seulement si pour tout $i$, $p[i] \succeq_{i} q[i]$ et il existe un entier $j$ tel que $p[j] \succ_{j} q[j]$. 
Le \emph{skyline}, illustr\'e figure \ref{fig:skyline}, est l'ensemble des points qui ne sont domin\'es par aucun autre point. 

\begin{figure}[!h]
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.4\textwidth]{fig/skyline}
		\caption{TODO franciser /// Exemple de jeu de donn\'ees bidimensionnel et son front de Pareto ou \emph{skyline}, pour un probl\`eme de minimisation (adapt\'e de \cite{papadias03optimal})}
	\label{fig:skyline}
\end{figure}

$\blacktriangleright${Exemple :}  
\bkcountfalse
\begin{breakbox}
En consid\'erant un probl\`eme de maximisation sur deux dimensions, la requ\^ete $skyline(date, nbDeFoisTelecharge)$ 
retourne le fichier le plus r\'ecent et le plus t\'el\'echarg\'e s'il existe, ou bien les fichiers tels qu'aucun 
autre fichier n'est plus r\'ecent sans \^etre moins t\'el\'echarg\'e et vice versa. 
\end{breakbox}
\vspace{0.6cm}

Une variante des requ\^etes skyline est la \emph{requ\^ete skyline sous contraintes} (de l'anglais << constrainted skyline query >>). 
Une requ\^ete skyline sous contraintes retourne l'ensemble des donn\'ees Pareto-optimales dans un sous-espace de l'espace des attributs 
d\'efini par une conjonction de pr\'edicats \cite{dellis06constrained}. 
% Formellement : %Soient $C={c_1,\ldots,c_d}$ un ensemble d'intervalles, avec $c_i=[]$
% Soit une conjonction de pr\'edicats d\'efinissant un hyper-rectangle $h$ dans l'espace des attributs,  
% l'ensemble des solutions \`a la requ\^ete skyline sous contraintes est $\{o \in \mathcal{O} | g(o) \in h$ et $\nexists p \in h : p \succ g(o) \}$. 
Une requ\^ete skyline sous contrainte est la composition d'une requ\^ete par intervalles par une requ\^ete skyline : elle est donc 
 de type hybride, \`a la fois de satisfaction et de comparaison. 
La figure \ref{fig:constrainedskyline} illustre sur un m\^eme jeu de donn\'ees le front de Pareto classique et un front de Pareto sous contraintes. 

\begin{figure}[!h]
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.55\textwidth]{fig/constrainedskyline}
		\caption{Exemple avec un front de Pareto (en pointill\'es) et un front de Pareto sous contraintes 
(gris\'e) (adapt\'e de \cite{dellis06constrained})}
	\label{fig:constrainedskyline}
\end{figure}

$\blacktriangleright${Exemple :}  
\bkcountfalse
\begin{breakbox}
En consid\'erant un espace d'attributs \`a 3 dimensions, la requ\^ete $skyline(date, nbDeFoisTelecharge, taille > 128Mo)$ 
retourne les fichier qui optimisent la nouveaut\'e et la popularit\'e tout en \'etant d'une taille minimale.
\end{breakbox}
%Nous adoptons dans le reste du document l'expression \emph{skyline}, selon la terminologie en vigueur dans les bases de donn\'ees. \\
\vspace{0.6cm}

Dans le cas o\`u la requ\^ete de skyline est calcul\'ee pour un sous-ensemble de dimensions, \cite{dellis06constrained} parle de \emph{requ\^etes skyline sur un sous-espace} 
(de l'anglais << subspace skyline queries >>). 
% La combinaison entre requ\^etes skyline sous contraintes et sur un sous-espace offre \`a l'utilisateur un outil puissant de s\'election parmi les donn\'ees
\footnote{Dans les exemples de requ\^etes skyline, en nous restreignant \`a un sous-ensemble d'attributs pertinents, nous avons implicitement utilis\'e des requ\^etes skyline sur un sous-espace.}. 

 \end{itemize}
% \vspace{0.6cm}
% D'autres types de requ\^etes rencontr\'es dans la litt\'erature sont les requ\^etes de type relationnel tel que la requ\^etes de jointure (cf. le syst\`eme
% PIER \cite{})


% \paragraph{\textit{Requ\^ete spatiales}}
% 
% \begin{itemize}
%   \item[~\textit{Requ\^ete~}\textit{d'intersection}~] ~
%   
%   \item[~\textit{Requ\^ete~}\textit{d'inclusion~}] ~
%   
%   \item[~\textit{Requ\^ete~}\textit{d'englobement~:}] ~
% \end{itemize}
% 
% \paragraph{\textit{Requ\^ete}\textit{\textit{s}}\textit{par
% similarit\'e}}
% 
% \begin{itemize}
%   \item[~\textit{Requ\^ete~}\textit{par~fen\^etrages}\textit{~}] ~
%   
%   \item[~\textit{Requ\^ete~}\textit{k~plus~proches~voisins}~\textit{(ou}]
%   \textit{k-PVV ou de plus proches voisins)~}:
%   
%   \item[~\textit{Requ\^ete~}\textit{skyline}~,] ~
% \end{itemize}
% 
% \paragraph{\textit{Requ\^ete }\textit{relationnelles}}
% 
% \begin{itemize}
%   \item[~\textit{Requ\^ete~}\textit{join}~] ~
%   
%   \item[~\textit{Requ\^ete~}\textit{d'aggr\'egation}~] ~
% \end{itemize}
% [top k queries : cygrid.org.cy/docs/dtopk.pdf][Def spatial queries
% http://cgi.cse.unsw.edu.au/ macheema/thesis/node6.html]

\section{Grille d'\'evaluation et crit\`eres requis} \label{sec:Grille d'\'evaluation ad hoc}
%Ce chapitre proc\`ede \`a une lecture orient\'ee de l'existant, \`a la lumi\`ere des besoins pr\'ecis \'enonc\'es dans le chapitre introductif. 
Avant de pr\'esenter un \'etat de l'art des solutions d'index distribu\'es, nous proposons une grille d'\'evaluation. 
%nous d\'ecrivons ici les diff\'erents plans qui nous ont sembl\'e pertinents pour approcher les solutions d'index existantes. 
Dans cette grille nous distinguons plusieurs dimensions : architecture d\'ecentralis\'ee, passage \`a l'\'echelle, maintenance, etc. 
Pour ces dimensions nous formulons cinq crit\`eres requis pas une solution d'index pour r\'epondre \`a notre probl\'ematique. 

% Une question que l'on peut se poser en premier lieu est le caract\`ere minimal et/ou complet de cet ensemble de crit\`eres. Faute de mod\`ele formel, nous ne sommes pas 
% en mesure de prouver l'une ou l'autre de ces propri\'et\'es. 
% Nous nous bornons donc ici \`a exposer des crit\`eres employ\`es commun\'ement dans la litt\'erature, et de relier
% chacun \`a un aspect particulier de la prob\'ematique de PosNet, telle qu'\'elabor\'ee dans l'introduction. 
%Nous pouvons consid\'erer que cet ensemble est complet dans la mesure o\`u il r\'epond \`a l'ensemble des objectifs de PosNet. 

\subsection{Mod\`ele d'architecture}
La gestion de donn\'ees dans les syst\`emes d'information fait traditionnellement appel \`a des index centralis\'es, tels que les syst\`emes de 
gestion de bases de donn\'ees traditionnels. Or dans le contexte dans lequel nous nous pla\c cons, cette approche achoppe sur plusieurs points : 
\begin{itemize}

\item \emph{Passage \`a l'\'echelle}. 
% Comme d\'evelopp\'e dans la suite de ce chapitre, 
% l'\'evolution d'un syst\`eme de gestion de donn\'ees pour lui permettre de prendre en compte un nombre croissant d'utilisateurs et 
% assurer une disponibilit\'e 24 h/24, 7j/7, passe par la distribution des donn\'ees sur plusieurs serveurs et la r\'epartition 
%sur celles-ci de la charge des requ\^etes utilisateur. 
% Or dans le cas des syst\`emes de gestion de bases de donn\'ees traditionnels,
% la d\'ecentralisation des donn\'ees et des traitements rentre en conflit avec les contraintes d'int\'egrit\'e forte qu'imposent les bases de donn\'ees relationnelles. 
%Ce verrou constitue la principale motivation pour la conception de solutions alternatives, mieux adapt\'ees \`a une architecture d\'ecentralis\'ees. 
Une architecture d\'ecentralis\'ee, distribue les donn\'ees et traitements sur un ensemble de serveurs. Cela permet d'\'eviter 
les ph\'enom\`enes de goulots d'\'etranglement et permet \'egalement de passer \`a l'\'echelle sans avoir \`a recourir \`a de puissants serveurs.

\item \emph{Co\^ut}. 
Pour monter en charge, un syst\`eme centralis\'e requiert une augmentation des capacit\'es individuelles de chaque 
serveur (toujours plus d'espace disque, de CPU, de RAM, etc.). Or nous nous pla\c cons dans le cas d'applications ne devant pas
n\'ecessiter de supercalculateurs. 
Les syst\`emes permettant un accroissement des capacit\'es << horizontal >>, c'est-\`a-dire par ajout de postes informatiques, sont donc pr\'ef\'erables dans notre contexte
 (le prix d'un processeur de petite puissance \'etant proportionnellement inf\'erieur au prix d'un processeur de grande puissance). %Par ailleurs, cette approche pr\'esente l'avantage de
%permettre le partage de ressources (donn\'ees, applications, p\'eriph\'eriques on\'ereux, etc.), et par l\`a, l'optimisation de leur utilisation 
%(au LIP6, le taux d'occupation moyen des serveurs et des processeurs est respectivement de 69\% et 93\% 
%\footnote{Source : Slides d'introduction aux syst\`eme \`a objets r\'epartis de Franck Singhoff}) 
%D'o\`u l'int\'er\^et d'approches d\'ecentralis\'ees, comme l'approche orient\'ee pair-\`a-pair qui mutualise les ressources
%  de participants mettant chacun \`a contribution une partie de leurs ressources informatiques. Au fur et \`a mesure que de nouveaux participants se joignent au syst\`eme, accroissant 
% sa charge, la capacit\'e totale du syst\`eme cro\^it aussi.

\item \emph{Efficacit\'e}. Le recours \`a une architecture r\'epartie permet de parall\'eliser les calculs concurrents, notamment le
 traitement des requ\^etes, et donc d'augmenter les performances du syst\`eme \`a des co\^uts inf\'erieurs \`a ceux d'un supercalculateur. 

% L'utilisation de plusieurs CPU permet d'obtenir de meilleures performances, de contourner les limitations li\'ees 
% \`a la vitesse de la m\'emoire (qui n'augmente pas de la
% m\^eme mani\`ere que celle des processeurs), d'anticiper le ralentissement de la loi de Moore (qui mod\'elise l'augmentation de la vitesse des processeurs), etc. 
 
%\item \emph{Confidentialit\'e des donn\'ees}. Certains syst\`emes d\'ecentralis\'es mutualisent les ressources des serveurs de
%particuliers. Ces syst\`emes permettent aux utilisateurs de conserver un contr\^ole local sur leurs donn\'ees. 
%Ne n\'ecessitant pas de programme propri\'etaire ou de serveur Web d'une tierce partie, ils offrent aux utilisateurs une meilleure protection de la confidentialit\'e de leurs 
%donn\'ees.

\item \emph{Prise en compte de la nature d\'ecentralis\'ee du probl\`eme}. Certains syst\`emes se mod\'elisent << naturellement >> de mani\`ere d\'ecentralis\'ee, 
lorsque les donn\'ees et/ou les utilisateurs sont g\'eographiquement dispers\'es par exemple. 

\item \emph{Maintenance}. Comme invoqu\'e par \cite{decandia07dynamo}, concevoir un syst\`eme dans lequel chaque n\oe ud poss\`ede le m\^eme r\^ole, 
sans qu'aucun ne rev\^ete de responsabilit\'e particuli\`ere 
par rapport \`a un autre, permet d'en simplifier la maintenance et l'allocation automatique de ressources.  

%\paragraph {\textbf{~~~Crit\`ere 3 (Sym\'etrie)}} \textit{Les n\oe uds du syst\`eme doivent \^etre interchangeables.}

\end{itemize} 

Consid\'erant les facteurs pr\'ec\'edents, nous explicitons l'importance pour PosNet d'une architecture d\'ecentralis\'ee en \'edictant le premier crit\`ere : 

\paragraph {\textbf{~~~Crit\`ere 1 (Indexation et localisation d\'ecentralis\'ee)}} \textit{Aucun processus ne connai\^it l'\'etat global du syst\`eme.
La prise de d\'ecision se fait uniquement \`a partir de connaissances partielles du syst\`eme.}

\subsection{Fonctionnement en syst\`eme ouvert}

%Nous nous pla\c cons dans l'hypoth\`ese d'un syst\`eme dynamique, dans lequel les ressources et la charge varient au cours du temps.
Nous visons les architectures sans partage, potentiellement form\'ees de centaines voire de milliers d'ordinateurs tout-venant distribu\'es g\'eographiquement, 
auxquels acc\`edent des milliers voire des millions d'utilisateurs. Ce syst\`eme est dynamique : les utilisateurs se connectent, se d\'econnectent, des pannes mat\'erielles ou r\'eseau 
se produisent, etc. L'administration manuelle d'un tel syst\`eme est complexe et fastidieuse.  
Dans cette hypoth\`ese de monde ouvert, les changements affectant le syst\`eme sont la norme plut\^ot que des accidents. Ce qui conduit \`a pr\'ef\'erer int\'egrer 
le facteur instabilit\'e au fonctionnement du syst\`eme plut\^ot que d'essayer de le pr\'evenir. 
Nous nous int\'eressons donc aux syst\`emes exhibant des propri\'et\'es d'auto-organisation et d'auto-stabilisation. 
Ces m\'ecanismes doivent permettre \`a un index de s'adapter automatiquement aux modifications de son environnement. 
%, tels que l'arriv\'ee ou le d\'epart d'une serveur, la variation du volume ou de la distribution des donn\'ees et des requ\^etes, etc.

Nous nous int\'eressons plus particuli\`erement \`a une forme d'adaptativit\'e, que l'on d\'esigne sous les termes de \emph{passage \`a l'\'echelle incr\'emental} (de l'anglais << auto-scaling >>). 
Le passage \`a l'\'echelle incr\'emental caract\'erise la capacit\'e pour un syst\`eme \`a int\'egrer \`a la vol\'ee de nouvelles ressources (nous parlerons de << n\oe ud >> dans la suite), 
sans que cela n\'ecessite d'intervention manuelle ou d'interruption du syst\`eme. En d'autres termes, la conception d'un syst\`eme auto-scalable minimise 
les effets de bord qu'occasionne sur le reste du syst\`eme l'insertion (ou la suppression) d'un n\oe ud. 
L'int\'egration de ces ressources au syst\`eme s'accompagnant d'un accro\^issement de ses capacit\'es lui permettant d'absorber une charge croissante. 

% L'application de ces m\'ecanismes conduit \`a maintenir la structure du syst\`eme et \`a en assurant la continuit\'e, sans toutefois en pr\'eserver 
% un \'equilibre immuable ou sans revenir \`a un \'etat ant\'erieur \`a la perturbation, mais au contraire en \'evoluant pour int\'egrer les modifications de l'environnement.  

%sans changer de structure qualitative.
% Par ailleurs, l'arr\^et du syst\`eme pour des op\'erations d'administration peut contrevenir \`a des contraintes de disponibilit\'e s'exer\c cant sur le syst\`eme 
% (par exemple dans le cas o\`u de l'index d\'epend une application tel qu'un portail Web devant \^etre disponible 7j/7, 24h/24). 

% et de s'adapter dynamiquement \`a la charge par ajout ou suppression \`a la vol\'ee de serveurs et ce, sans entra\^iner d'interruption du syst\`eme gr\^ace \`a des 
% m\'ecanismes d'auto-configuration et d'auto-stabilisation. 
% capable de de g\'erer des ressources allou\'ees/d\'esallou\'ees dynamiquement, sans n\'ecessiter
% de modification de la configuration mat\'erielle ou logicielle du syst\`eme. 

\paragraph {\textbf{~~~Crit\`ere 2 (Passage \`a l'\'echelle incr\'emental)}} \textit{
Le syst\`eme doit pouvoir s'adapter automatiquement \`a la quantit\'e de n\oe uds disponibles}

% \subsection{Fonctionnement en syst\`eme ouvert}
% 
% Comme invoqu\'e par \cite{decandia07dynamo}, concevoir un syst\`eme dans lequel chaque n\oe ud poss\`ede le m\^eme r\^ole, 
% sans qu'aucun ne rev\^ete de responsabilit\'e particuli\`ere 
% par rapport \`a un autre, permet d'en simplifier la maintenance et l'allocation automatique de ressources (\emph{provisioning} en anglais).  
% 
% \paragraph {\textbf{~~~Crit\`ere 3 (Gestion du dynamisme)}} \textit{Les n\oe uds du syst\`eme doivent \^etre interchangeables.}

% \subsection{Flexibilit\'e}
% % De mani\`ere g\'en\'erale, les diff\'erentes g\'eom\'etries, dont celles d\'etaill\'ees ci-dessous, se valent au regard du compromis \'etat/efficacit\'e.
% % C'est ainsi que Gummadi \emph{\emph{\emph{et al.}}} proposent dans leur \'etude \cite{gummadi03impact} de diff\'erentier les g\'eom\'etries de routage 
% % non plus sur les crit\`eres d'\'etat ou d'efficacit\'e, mais sur celui de la \emph{flexibilit\'e}. 
% % Les auteurs caract\'erisent la flexibilit\'e d'une g\'eom\'etrie comme le degr\'e de libert\'e dont dispose un n\oe ud 
% % dans le choix i) de ses voisins, ii) des routes. Lors de la constitution et de la maintenance des tables de routage, la g\'eom\'etrie permet-elle
% % \`a un n\oe ud de choisir ses voisins (par exemple en fonction de la proximit\'e) ou bien le choix est-il d\'eterministe ? Pour une table et une destination donn\'ees,
% % la g\'eom\'etrie permet-elle \`a un n\oe ud de  choisir le prochain saut ? 
% 
% %TODO d\'evelopper sur le sujet de la robustesse. Les diff\'erents m\'ecanismes. Parmi les m\'ecanismes : la flexibilit\'e. 
% Gummadi \emph{et al.} caract\'erisent dans leur \'etude \cite{gummadi03impact} la flexibilit\'e dans un overlay comme le degr\'e de libert\'e qui subsiste une fois fix\'ee la 
% ma g\'eom\'etrie de routage de base. Cette libert\'e peut s'exercer dans le choix (i) des voisins, (ii) des routes. 
% \paragraph{S\'election du voisinage :} Dans certaines solutions le choix des voisins est totalement d\'eterministe
% (\'etant donn\'e un ensemble d'identifiants de n\oe uds, les tables de routage sont compl\`etement d\'etermin\'ees). Dans d'autres, un degr\'e de libert\'e 
% existe dans le choix des voisins, ce qui permet de prendre en compte une vari\'et\'e de crit\`eres, comme l'h\'et\'erog\'eit\'e des n\oe uds (en termes de ressources) ou la 
% promixit\'e r\'eseau (latence) ; 
% 
% \paragraph{S\'election des routes :} \'Etant donn\'es un ensemble de voisins et une requ\^ete, le protocole de routage d\'etermine le prochain saut, c'est-\`a-dire le prochain n\oe ud
% auquel transmettre la requ\^ete. Cette libert\'e est importante pour deux raisons. La premi\`ere raison tient \`a la robustesse du syst\`eme. 
% Lorsque l'algorithme de routage s\'electionne un voisin qui est en panne, 
% la flexibilit\'e d\'ecrit le nombres d'alternatives dont dispose un n\oe ud. Si le nombre est r\'eduit voire nul, 
% alors il est probable que l'algorithme de routage se montre peu r\'esilient en cas de fr\'equence \'elev\'ee de pannes. 
% La seconde raison tient \`a l'optimisation des routes. Un degr\'e de libert\'e dans le choix de la route permet de s\'electionner 
% sur crit\`eres, par exemple la proximit\'e (ou localit\'e) g\'eographique qui permet de r\'eduire la latence.  
% % entre autres, le degr\'e de libert\'e 
% % %dont dispose un n\oe ud dans le choix du n\oe ud suivant auquel transmettre une requ\^ete donn\'ee.
% % dont dispose un n\oe ud dans le choix du n\oe ud auquel transmettre une requ\^ete.  
% 
% \paragraph {\textbf{~~~Crit\`ere 4 (Flexibilit\'e dans le choix des routes)}} \textit{Dans un \'etat donn\'e et pour une destination donn\'ee, le syst\`eme 
% a le choix entre plusieurs routes.}


\subsection{Gestion des donn\'ees}

% Parmi les types d'index, une famille important est constitu\'e des index cl\'e-valeur. Ces index offrent les fonctionnalit\'es d'une table de hachage.  
% % on distingue deux familles, selon que les donn\'ees sont index\'ees en fonction d'une cl\'e ou en fonction de leur valeur. Dans le premier cas, 
% % indexation et localisation reposent sur l'utilisation d'une fonction de hachage, ce qui permet un traitement efficace des requ\^etes exactes
% Indexation et localisation reposent sur l'utilisation d'une fonction de hachage, ce qui permet un traitement efficace des requ\^etes exactes
%  (API de type put(key, value), get(key)). 

De nombreux index distribu\'es reposent sur l'utilisation de fonctions de hachage, pour leurs propri\'et\'es de r\'epartition des donn\'ees dans l'esapace d'arriv\'ee, la simplicit\'e de la transformation, l'efficacit\'e des algorithmes de recherche exacte.
En effet, le hachage projetant l'espace multidimensionnel des attributs sur l'espace unidimensionnel des empreintes, 
les seules requ\^etes nativement support\'ees sont les requ\^etes exactes, portant sur une cl\'e suppos\'ee connue \emph{a priori}.
Puisque nous nous int\'eressons dans cette th\`ese aux m\'ethodes d'acc\`es par le contenu sur des donn\'ees multidimensionnelles, un premier requis est donc le non recours 
au hachage des cl\'es des donn\'ees. 

L'\'elaboration de telles m\'ethodes se heurte \`a l'absence d'ordre total d\'efinissable sur un ensemble de donn\'ees multidimensionnelles qui pr\'eserve la \emph{localit\'e}. 
En d'autres termes, il n'existe pas de fonction d'un espace \`a deux dimensions (ou plus) vers un espace \`a une dimension qui permette de garantir que 
deux donn\'ees proches dans un espace multidimensionnel soient proches dans une s\'equence ordonn\'ee unidimensionnelle \cite{gaede98multidimensional}. 
Or l'efficacit\'e du traitement des requ\^etes d'intervalles et des requ\^etes de comparaison repose sur la localit\'e spatiale des donn\'ees.  
Pour ces raisons, %la gestion \`a la fois de donn\'ees multi-dimensionnelles et de requ\^etes complexes rend 
la conception de m\'ethodes d'acc\`es est rendue plus complexe que dans le cas standard des bases de donn\'ees, qui emploie des m\'ethodes d'acc\`es uni-dimensionnelles.
%D'o\`u la difficult\'e de concevoir des algorithmes de recherche efficaces pour les requ\^etes par intervalles ou de comparaison.   
Le probl\`eme est contourn\'e par certaines solutions, notamment de base de donn\'ees, qui g\`erent les requ\^etes multidimensionnelles en maintenant 
un index unidimensionnel s\'epar\'e par attribut (pour un exemple d'une telle approche dans les overlays P2P, voir Mercury d\'ecrit 
plus bas en \ref{subsubsec:Utilisation d'une fonction de hachage pr\'eservant la localit\'e : Exemple de MAAN}). 
Toutefois cette approche impose, outre la cr\'eation et la maintenance de $d$ index au lieu d'un, un surco\^ut lors du traitement de chaque requ\^ete (par exemple : d\'ecomposition de la requ\^ete multidimensionnelle en sous-requ\^etes, ex\'ecutions multiples, op\'eration d'intersection des r\'esultats partiels, etc.). 
Gaede souligne qu'il n'y a pas, de mani\`ere g\'en\'erale, de fa\c con simple d'\'etendre une solution unidimensionnelle pour la rendre
multidimensionnelle. 

Pour des raisons d'efficacit\'e, nous posons donc une condition sur la gestion native des donn\'ees multidimensionnelles.
%S'il est possible de b\^atir des requ\^etes de plus haut niveau au-dessus de simples requ\^etes cl\'e-valeur (comme le montre la recherche exhaustive de l'exemple ci-dessus), 
Plus pr\'ecis\'ement, nous \'ecartons les approches par d\'ecomposition d'une requ\^ete en sous-requ\^etes plus simples, 
ou bien les approches par couches imposant des pr\'e-traitements aux donn\'ees pour pouvoir les adapter \`a l'index. 
% (ce qui exclu les solutions bas\'ees sur le hachage et leurs extensions multidimensionnelles). 

%Inefficacit\'e des recherches sur plusieurs attributs simultan\'ement dans les index reposant sur le hachage des donn\'ees =>

\paragraph {\textbf{~~~Crit\`ere 3 (Gestion native des donn\'ees multidimensionnelles)}} \textit{Le syst\`eme doit supporter les donn\'ees multidimensionnelles et
 prendre en compte simultan\'ement l'ensemble des attributs des donn\'ees lors de l'indexation et de la localisation.}

\subsection{Gestion des requ\^etes}
Le langage de requ\^ete employ\'e par un syst\`eme doit \^etre en mesure de d\'ecrire les donn\'ees acc\'ed\'ees avec un degr\'e
suffisant de d\'etails. 
Les recherches par cl\'e ne sont pas suffisamment expressives pour la recherche d'informations dans des documents texte, et
les recherches par mots-cl\'es ne sont pas suffisamment expressives dans le cas de donn\'ees structur\'ees, telles les 
tables relationnelles. 
%Parmi les types d'index, une famille important est constitu\'ee des index cl\'e-valeur. Ces index offrent les fonctionnalit\'es d'une table de hachage.  
%Les op\'erations d'indexation et de localisation reposent sur l'utilisation d'une fonction de hachage, ce qui permet un traitement efficace des requ\^etes exactes. Toutefois la recherche par mot-cl\'e ne suffit pas toujours. 
Dans le contexte de cette th\`ese, nous nous int\'eressons particuli\`erement aux requ\^etes par intervalles ou plages de valeurs et aux requ\^etes de comparaison. 
Les requ\^etes par intervalles sont essentielles dans le cas d'attributs num\'eriques \cite{cai04maan}, comme l'illustre l'exemple suivant :

%$\blacktriangleright${Exemple :}  
\bkcountfalse
\begin{breakbox}
Alexandra d\'esire trouver un morceau de Nina Simone dont elle ne se rappelle pas du nom, mais qui date des ann\'ees 60. 
Dans le cas d'une recherche par cl\'e, elle doit se contenter de rentrer une par une 
les dates exactes de tous les albums produits dans les ann\'ees 60 (soit un total de 10 requ\^etes). Puis de rechercher parmi l'union des r\'esultats retourn\'es par chaque requ\^ete. 
Une requ\^ete par intervalles de valeurs aurait permis d'exprimer la requ\^ete de fa\c con plus concise, en une seule fois : (artiste=<< Nina Simone >>, 1959<date<1970).
\end{breakbox}
\vspace{0.6cm}
Concernant les requ\^etes de comparaison, elles sont indispensables pour l'exploration des donn\'ees. Elle permettent la recherche des donn\'ees
pr\'esentant les meilleurs compromis (dans le cas multidimensionnel, un optimum global n'existe pas forc\'ement), 
la recherche des donn\'ees les plus pertinentes selon un crit\`ere donn\'e (et de limiter \'eventuellement le nombre de solutions retourn\'ees par une requ\^ete)
ou encore la recherche de donn\'ees par similarit\'e (si une donn\'ee est pertinente, alors les donn\'ees similaires pr\'esentent de grandes chances de l'\^etre aussi). 
Les requ\^etes de comparaison ont des champs d'application vari\'es, comme le d\'emontre l'abondance des travaux dans le domaine des syst\`emes centralis\'es 
(se reporter \`a \cite{papadias03optimal} pour une \'etude exhaustive) : 
d\'ecision multi-crit\`eres, syst\`emes de monitoring, extraction d'information, bases de donn\'ees multim\'edia, analyse de donn\'ees spatiales, etc.
Parmi les requ\^etes de comparaison, les requ\^etes de front de Pareto permettent \`a l'utilisateur de s\'electionner les donn\'ees pr\'esentant 
le meilleur compromis entre des crit\`eres contradictoires. 
%La combinaison entre requ\^etes skyline sous contraintes et sur un sous-espace offre \`a l'utilisateur un outil puissant de s\'election parmi les donn\'ees

$\blacktriangleright${Exemple d'utilit\'e d'une requ\^ete de front de Pareto :}  
\bkcountfalse
\begin{breakbox}
Alexandra d\'esire trouver parmi les derniers morceaux sortis, ceux qui sont les mieux not\'es par les autres utilisateurs. 
\end{breakbox}
\vspace{0.6cm}
% La localisation de donn\'ees est le plus souvent employ\'ee en mode interactif. 
% Si dans le cas des 
% Il est donc important que l'index fournisse les premi\`eres solutions rapidement, puis les suivantes
% au fur et \`a mesure que progresse la recherche. 
% Or ce n'est pas le cas des algorithmes qui fonctionnent en mode batch, qu'ils requi\'erent une recherche exhaustive ou bien un post-traitement sur des r\'esultats interm\'ediaires. 
% Nous d\'esignons cette propri\'et\'e sous le terme de \emph{progressivit\'e}. 

Par-ailleurs, la localisation de donn\'ees est le plus souvent employ\'ee en mode interactif. 
Il est donc important que l'index fournisse les premi\`eres solutions rapidement, puis les suivantes
au fur et \`a mesure que progresse la r\'esolution de la requ\^ete. 
Or ce n'est pas le cas des algorithmes qui fonctionnent en mode << batch >>, qui requi\`erent une recherche exhaustive ou bien un post-traitement sur des r\'esultats interm\'ediaires. 
Nous d\'esignons cette propri\'et\'e sous le terme de \emph{progressivit\'e}. 

\paragraph {\textbf{~~~Crit\`ere 4 (Gestion de requ\^etes par intervalles et de comparaison)}} 
%\paragraph {\textbf{~~~Crit\`ere 4 (Progressivit\'e des requ\^etes)}} 
\textit{Le syst\`eme doit supporter des requ\^etes par intervalles et de comparaison, notamment les requ\^etes skyline et retourner les solutions de mani\`ere progressive.}

%\textit{Le syst\`eme doit offrir des fonctionnalit\'es \'evolu\'ees de recherches. Nous nous int\'eressons notamment \`a tous les types de requ\^etes trait\'es en section \ref{modele-index}.}
%\paragraph {\textbf{~~~Crit\`ere 5 (Gestion native des requ\^etes de comparaison)}} \textit{} \\
  
% Revenons sur la r\'ef\'erence \`a un ordre bas\'e sur la s\'emantique. 
% Les requ\^etes par intervalles de valeurs ou de comparaison ont pour objet la recherche de donn\'ees corr\'el\'ees, ou proches s\'emantiquement. 
% Leur ex\'ecution est donc rendue plus efficace 
% lorsque la localit\'e s\'emantique de ces donn\'ees est pr\'eserv\'ee par la proc\'edure d'indexation : informellement, deux donn\'ees consid\'er\'ees comme proches (en termes de s\'emantique)
% sont alors stock\'ees par l'index dans un voisinage proche (en termes de distance de communication). Autrement dit, 
% lorsque la localit\'e s\'emantique des donn\'ees est pr\'eserv\'ee, la recherche dans l'index de donn\'ees proches s\'emantiquement se ram\`eme alors \`a une
% recherche dans un espace. L'\'etude de l'existant \`a venir s'attache donc plus particuli\`erement aux solutions d'index pr\'eservant un ordre sur les donn\'ees, ainsi qu'\`a 
% l'\'etude de la corr\'elation entre les caract\'eristiques d'un ordre et les fonctionnalit\'es de recherches qui en d\'ecoulent. 

%(avec en corollaire la non-utilisation de fonction de hachage). 
% Si beaucoup de solutions d'index d\'ecentralis\'e r\'epondent aux crit\`eres 1, 2, 3 et 4, peu adressent aussi le crit \`ere 5, ne serait-ce que pour proposer un seul type de requ\^ete
% de comparaison. 

% \subsection{Utilisation interactive}
% 
% \paragraph {\textbf{~~~Crit\`ere ? (Progressivit\'e)} Le syst\`eme doit retourner } 

\subsection{Qualit\'e de service}

Diff\'erentes m\'etriques peuvent servir \`a mesurer la qualit\'e de service d'un index, selon l'application consid\'er\'ee. Parmi ces m\'etriques on trouve 
la latence, le nombre total de solutions retourn\'ees (pour une requ\^ete partielle, par exemple) ou encore la pr\'ecision (le nombre de r\'eponses pertinentes sur le nombre de r\'eponses retourn\'ees pour une requ\^ete de mots cl\'es, par exemple), etc.

Une m\'etrique d'\'evaluation est la \emph{compl\'etude} de la recherche. Elle est mesur\'ee par le taux de rappel : 
le rapport du nombre de solutions pertinentes retourn\'ees sur le nombre total de solutions pertinentes index\'ees. 
Si certains cas d'utilisation ne recherchent qu'une seule solution ($1$ parmi $n$), d'autres applications recherchent toutes les solutions possibles. 
Pour satisfaire ces applications, nous posons un crit\`ere de compl\'etude des recherches, excluant les recherches par force brute et les approches probabilistes. 

%\paragraph {\textbf{~~~Crit\`ere 5 (Recherche efficace)}} \textit{Les processus doivent communiquer de mani\`ere \`a pouvoir coop\'erer efficacement dans les recherches.} \\
\paragraph {\textbf{~~~Crit\`ere 5 (Recherche efficace)}} \textit{Le syst\`eme doit retourner pour une requ\^ete donn\'ee toutes les solutions pertinentes et seulement les solution pertinentes.} 

%Diff\'erentes m\'etriques peuvent servir \`a mesurer la qualit\'e de service d'un index, selon l'application consid\'er\'ee. Parmi ces m\'etriques d'\'evaluation on trouve par exemple la latence ou le nombre total de solutions retourn\'ees. 
%Nous nous int\'eressons aux deux crit\`eres suivants : 
%\begin{enumerate}
%	\item La \emph{pr\'ecision} de la recherche, mesur\'ee par le rapport entre le nombre de r\'eponses pertinentes et le nombre de r\'eponses retourn\'ees pour une requ\^ete de mots cl\'es, par exemple) ;
%	\item La \emph{compl\'etude} de la recherche, mesur\'ee par le taux de rappel : 
%le rapport entre le nombre de solutions pertinentes retourn\'ees et le nombre total de solutions pertinentes index\'ees. 
%Si certains cas d'utilisation ne recherchent qu'une seule solution ($1$ parmi $n$), d'autres applications recherchent toutes les solutions possibles. 
%\end{enumerate}
 
%Pour satisfaire ces applications, nous posons un crit\`ere de compl\'etude des recherches, excluant les recherches par force brute et les approches probabilistes. 

%\paragraph {\textbf{~~~Crit\`ere 5 (Recherche efficace)}} \textit{Les processus doivent communiquer de mani\`ere \`a pouvoir coop\'erer efficacement dans les recherches.} \\
%\paragraph {\textbf{~~~Crit\`ere 5 (Recherche efficace)}} \textit{Le syst\`eme doit retourner pour une requ\^ete donn\'ee toutes les solutions pertinentes et seulement les solution pertinentes.} 
%\vspace{0,6cm}


\paragraph{}Cette section a \'etabli une grille de lecture que nous utilisons par la suite, pour \'etudier les solutions existantes. 
Les cinq crit\`eres d\'efinis pr\'ec\'edemment permettent aussi de distinguer les solutions pertinentes pour notre probl\'ematique. 
% Nous avons omis certains crit\`eres sciemment : principalement la r\'epartition de la charge et la tol\'erance aux pannes. La r\'epartition de la charge notamment
%  affecte directement le passage \`a l'\'echelle de la solution. Ces deux aspects n'\'etant pas encore trait\'es pleinement dans PosNet, nous faisons le choix de ne pas
% consid\'erer l'existant sur leur base. 

L'\'etude de de l'existant se d\'eroule en trois temps. 
Nous l'abordons par un tour d'horizon de domaines connexes en \ref{subsec:Domaines connexes}, dont la connaissance permettra 
de d\'elimiter le champ des index distribu\'es. 
Puis nous d\'etaillons en \ref{basedonnees-dds-bds} deux approches issues du domaine des bases de donn\'ees, 
les syst\`emes de donn\'ees distribu\'es et les bases de donn\'ees spatiales, pr\'esentant une grande proximit\'e avec
notre approche. 
Enfin, une classification des solutions d'index P2P est propos\'ee en \ref{subsec:etudesoverlaysstructures}. Au terme de cette classification, nous restreignons 
le champ des solutions aux propositions directement comparables \`a la notre et nous en exhibons les limitations au regard des crit\`eres postul\'es ci-avant.  

\section{Etat de l'art : en-dehors de l'approche P2P} \label{sec:Etat de l'art : en-dehors de l'approche P2P}
%les index distribu\'es}
La recherche dans le domaine des index s\'emantiques d\'ecentralis\'es se situe au confluent de plusieurs autres domaines : les bases de donn\'ees, les r\'eseaux, l'informatique distribu\'ee, l'extraction d'information.
%Cette section a pour objectif de situer les 
Parmi ce panel de syst\`emes, les bases de donn\'ees spatiales et les solutions de stockage de donn\'ees distribu\'ees (de l'anglais << distributed data stores >>) pr\'esentent des objectifs et une approche qui les apparentent fortement \`a nos travaux. 
%Nous terminons donc cette section en \'etudiant dans le d\'etail leurs cas.  
Nous parcourons ces domaines \`a l'aune des crit\`eres \'etablis pr\'ec\'edemment.  
% Parmi les travaux connexes, nous distinguons le domaine des bases de donn\'ees, qui repr\'esente l'approche de r\'ef\'erence pour la gestion de donn\'ees, 
% des domaines connexes, distincts du notre mais pr\'esentant une communaut\'e d'int\'er\^ets.

\subsection{Domaines connexes}\label{subsec:Domaines connexes}
Cette section propose un survol de quelques syst\`emes d'information distribu\'es et techniques de recherche ayant des objectifs comparables aux notres, et qui ont parfois inspir\'e des solutions d'index P2P. 

\paragraph{Serveurs de noms de domaine}
Le syst\`eme de noms de domaine DNS est un ensemble de serveurs de nommage sur Internet. 
Sa fonction est principalement de r\'esoudre des noms de domaine ou des noms de serveurs en adresses IP (ou vice versa). 
Son utilit\'e est de permettre une meilleure usabilit\'e du Web, en dispensant l'utilisateur de manipuler des adresses num\'eriques. 
% Au lieu de quoi, l'utilisateur 
% entre dans son navigateur l'adresse Web (ou URL) des ressources recherch\'ees (document HTML, image, forum Usenet, etc.). 
% De mani\`ere totalement transparente pour lui, l'URL est d'abord convertie par le DNS en adresse IP selon une proc\'edure dite de << r\'esolution >> d'adresse, afin que la
% requ\^ete de recherche puisse \^etre achemin\'ee \`a destination. 
Le DNS est une solution qui a su se maintenir depuis les d\'ebuts de l'Internet gr\^ace \`a son aptitude \`a passer \`a l'\'echelle et \`a son caract\`ere distribu\'e et hi\'erarchique
 (cf. figure \ref{fig:espaceNomsDomaine}). 

En termes de mod\`ele d'index, un syst\`eme DNS est un index cl\'e-valeur distribu\'e. Les cl\'es sont les noms symboliques et les valeurs sont les adresses IP. 
Le syst\`eme est soumis \`a des contraintes fortes de passage \`a l'\'echelle (le nombre d'adresses IP se compte en milliards, 
le nombre d'utilisateurs en milliers de millions, un utilisateur peut effectuer 
des centaines de requ\^etes par jour, etc.) et de dynamicit\'e (l'ensemble des noms de domaines et celui des IP \'evolue quotidiennement).
Ces contraintes sont g\'er\'ees \`a l'aide d'une structure de donn\'ees adapt\'ee, maintenue par une architecture distribu\'ee de type client-serveur. 
L'espace des noms de domaine est d\'ecoup\'e de mani\`ere r\'ecursive et organis\'e selon une structure d'arbre.
Cette structure est distribu\'ee sur un ensemble de serveurs. 
Chaque serveur est responsable d'un ou plusieurs sous-arbres ou zones DNS. 
%Une zone DNS peut \^etre supervis\'ee par un ou plusieurs serveurs. 
Les serveurs n'ayant qu'une connaissance partielle des noms et des autres serveurs, la r\'esolution d'adresse peut n\'ecessiter la coordination de plusieurs serveurs. 
% Quelque soit la requ\^ete de r\'esolution initiale, le protocole commence par interroger le serveur responsable
% de la zone DNS \`a la racine de l'arbre des noms de domaine. 
La t\^ache de coordination est centralis\'ee au niveau du serveur DNS local. 
%Celui-ci re\c coit les requ\^etes utilisateurs. S'il ne poss\`ede pas l'adresse compl\`ete dans ses
%tables,  
%il initie le protocole de r\'esolution. Le protocole ex\'ecute un parcours en profondeur de l'arbre des noms de domaine, en commen\c cant par
%un serveur de niveau $n=0$ (responsable d'une zone DNS \`a la racine de l'arbre). A chaque niveau $n$, l'IP du serveur DNS de niveau $n+1$ est retourn\'ee au serveur DNS local, 
%qui lui transmet la requ\^ete. La r\'esolution aboutit lorsque la requ\^ete parvient aux serveurs DNS responsables de la ou les adresses requises.         
%\begin{figure}[!h]
%	\centering
%	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
%		\includegraphics[width=0.7\textwidth]{fig/espaceNomsDomaine.png}
%		\caption{Illustration d'un espace de noms de domaine et de sa partition en zones, supervis\'ees par les serveurs DNS 
%(adapt\'ee de Wikipedia)}
%	\label{fig:espaceNomsDomaine}
%\end{figure}

Le syst\`eme DNS est un exemple d'index utilisant une structure de donn\'ees distribu\'ee sur 
un ensemble de serveurs. Les techniques de passage \`a l'\'echelle tel que le recours \`a des serveurs cache pour traiter des requ\^etes 
th\'eoriquement adress\'ees aux serveurs racine, sont de nature \`a inspirer la conception d'architectures distribu\'ees \`a grande \'echelle. 
% afin de pr\'eserver les performances de la dizaine de serveurs racine dans le monde). 
Toutefois, %so un DNS est distribu\'e, il demeure sous contr\^ole centralis\'e. Par ailleurs, 
les fonctionnalit\'es de serveur de nommage ne permettent pas de satisfaire aux crit\`eres 3 et 4 concernant l'expressivit\'e des recherches. 

\paragraph{Syst\`emes de fichiers distribu\'es}
Un syst\`eme de fichiers distribu\'e permet d'acc\'eder de fa\c con concurrente \`a des fichiers distants et ce de mani\`ere transparente et concurrente. 
L'acc\`es se fait par l'interm\'ediaire d'un protocole r\'eseau contr\^olant notamment les droits utilisateurs.  
Le passage \`a l'\'echelle et son corollaire, la n\'ecessit\'e d'une architecture distribu\'ee, sont des probl\'ematiques qui, dans le domaine de syst\`emes de 
fichiers distribu\'es, remontent \`a la fin des ann\'ees 80 \cite{satyanarayanan89asurvey}. Une r\'ef\'erence est le syst\`eme de fichiers distribu\'es 
Andrew File System ou AFS \cite{morris86andrew}, con\c cu \`a l'origine pour une utilisation au sein du campus universitaire de Carnegie Mellon. La strat\'egie de 
passage \`a l'\'echelle d'AFS est bas\'ee sur des politiques de cache. 
%Ficus \cite{reiher94resolving} et 
Successeur de AFS, Coda \cite{satyanarayanan90coda} est d\'evelopp\'e en r\'eponse \`a la robustesse limit\'ee d'AFS. Coda poursuit un objectif de disponibilit\'e totale des fichiers
par la voie de la r\'eplication, au d\'etriment de la coh\'erence. 
La gestion de conflits lors de la synchronisation des modifications fait intervenir des protocoles sp\'ecifiques de r\'esolution de conflits. 
Farsite \cite{adya02farsite} n'emploie aucun serveur comme c'est le cas avec NFS. Ses crit\`eres de conception rejoignent notre crit\`ere 1, en faisant le choix d'une
 architecture d\'ecentralis\'ee pour des question de co\^uts, de confidentialit\'e et de robustesse en cas de panne g\'eographiquement localis\'ee.    
Enfin, le syst\`eme de fichiers distribu\'e propri\'etaire de Google, GFS \cite{ghemawat03google} est utilis\'e pour leurs propres applications. 
Il est optimis\'e pour la gestion de fichiers de taille importante (jusqu'\`a plusieurs giga-octets), pour le traitement d'op\'erations sp\'ecifiques 
(les fichiers sont tr\'es rarement supprim\'es ou r\'e\'ecrits, la plupart des acc\`es portent sur de larges zones et consistent surtout en des lectures ou des ajouts en fin de fichier).
GFS est pr\'evu pour s'ex\'ecuter sur les clusters de Google, sous des conditions qui correspondent \`a l'hypoth\`ese de monde ouvert postul\'e au crit\`ere 2. 
L'architecture de GFD est assez simple : chaque cluster
poss\`ede un unique serveur ma\^itre et un ensemble de serveurs de stockage. Le ma\^itre ne stocke pas de fichiers mais remplit le r\^ole d'index. 
%En tant que point sensible du syst\`eme, il poss\`ede un miroir constamment tenu \`a jour et capable de le remplacer en cas de prob\`eme. 
Pour \'eviter qu'il ne devienne un goulot 
d'\'etranglement, les protocoles sont con\c cus pour \'eviter au maximum les interactions directes clients/serveur ma\^itre. 
Les fichiers sont d\'ecoup\'es en morceaux (\emph{chunks}), d\'epos\'es sur les serveurs de stockage. Ceux-ci g\`erent les acc\`es en \'ecriture et en lecture de mani\`ere
\`a assurer la coh\'erence des r\'eplicats. 

A la diff\'erence des index P2P qui supportent uniquement un espace de nommage plat, les syst\`emes de fichiers distribu\'es g\`erent typiquement les domaines de nommage hi\'erarchiques. 
Il existe n\'eanmoins des rapprochements entre les deux domaines. 
%comme le d\'emontre l'\'etude \cite{hasan05survey} dans son analyse critique d'un panel de solutions de syst\`emes de fichiers bas\'es P2P.
Un exemple de solution de syst\`eme de fichiers bas\'e P2P est Pastis \cite{busca05pastis}, d\'evelopp\'e conjointement par l'INRIA et l'UPMC. 
Pastis est bas\'e sur l'overlay P2P Past \cite{druschel01past}, lui-m\^eme construit au-dessus de Pastry\cite{rowstron01pastry}. 
Nous ne d\'eveloppons pas davantage ces aspects, n'\'etant pas concern\'es par les mod\`eles hi\'erarchiques de donn\'ees, ni par l'impl\'ementation d'interfaces 
de type POSIX pour les op\'erations sur les fichiers et les dossiers. 
% RESUME EN ANGLAIS : %[http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html]
% %Compared to P2P storage systems that only support flat namespaces, distributed file systems typically support hierarchical namespaces. 
% Systems like Ficus [reiher94resolving] 
% and Coda [satyanarayanan87resilient] replicate files for high availability at the expense of consistency. 
% Update conflicts are typically managed using specialized conflict 
% resolution procedures. The Farsite system [adya02farsite] is a distributed file system that does not use any centralized server like NFS. 
% Farsite achieves high availability 
% and scalability using replication. The Google File System [ghemawat03google] is another distributed file system built for hosting the state of 
% Google?s internal applications. 
% GFS uses a simple design with a single master server for hosting the entire metadata and where the data is split into chunks and stored in chunkservers. 
% Bayou is a distributed relational database system that allows disconnected operations and provides eventual data consistency [terry95managing].
% Among these systems, Bayou, Coda and Ficus allow disconnected operations and are resilient to issues such as network partitions and outages. 
% These systems differ on their conflict resolution procedures. For instance, Coda and Ficus perform system level conflict resolution and Bayou allows 
% application level resolution. All of them, however, guarantee eventual consistency. Similar to these systems, Dynamo allows read and write operations 
% to continue even during network partitions and resolves updated conflicts using different conflict resolution mechanisms. 

\paragraph{Extraction d'Information}
Le domaine de l'extraction d'information (ou IR pour << Information Retrieval >>) recouvre les techniques de recherche d'information dans des documents textuels 
(ou dans les m\'etadonn\'ees d\'ecrivant ces
documents). Si les probl\'ematiques d'indexation et d'interrogation par le contenu sont famili\`eres \`a l'IR aussi, elles ont pour substrat
exclusif les documents texte (sans structure ou semi-structur\'es). Or la manipulation de documents texte couvre des probl\'ematiques sp\'ecifiques, li\'ees \`a l'impr\'ecision
intrins\`eque de leurs repr\'esentations. Ainsi les pr\'eoccupations li\'ees \`a l'indexation automatique par extraction de descripteurs (lemmatisation,
\ldots), au degr\'e de pertinence d'une solution par rapport \`a une requ\^ete, \`a l'interaction avec l'utilisateur (expansion de requ\^etes, \ldots) 
se situent en-dehors de notre probl\'ematique. 
%D'autres distinctions entre index
% P2P et syst\`emes de RI (SRI) sont avanc\'ees par Bawa, Manku \emph{\emph{\emph{et al.}}} dans \cite{bawa03sets} : nombre beaucoup plus important de n\oe ud pour les
% r\'eseaux P2P ; taux de \textit{churn }plus \'elev\'e \'egalement ; mod\`ele de donn\'ees plus homog\`ene (langage de description de ressources commun) ;
% absence de point de centralisation tel que les m\'ediateurs qui dans les SRI reformulent les requ\^etes ; sym\'etrie des pairs (\`a la fois producteurs
% et consommateurs d'information), etc.
pSearch \cite{tang03psearch} (qui est \'evoqu\'e de nouveau en \ref{subsec:G\'eom\'etrie en tore $d$-dimensionnel}) 
et PlanetP \cite{cuenca-acuna03planetp} 
constituent des exemples de rapprochement entre le paradigme P2P et les techniques issues de l'extraction d'information
pour la r\'esolution de requ\^etes de similarit\'e sur des documents texte. % (avec notamment l'utilisation du mod\`ele dit de vecteurs ou \emph{vector model}).    

\paragraph{Informatique ubiquitaire}
Le concept d'informatique ubiquitaire ou << ambiante\~ >>, c'est \`a dire omnipr\'esente, d\'esigne un mode d'interaction homme-serveur 
dans lequel les objets de notre quotidien servent d'interface. L'informatique ubiquitaire se pose en rupture avec l'usage courant de l'informatique, faisant intervenir
des postes de travail. Dans la vision << ambiante >>, l'utilisateur humain est immerg\'e au sein d'un r\'eseau \'etendu de composants \'electroniques miniaturis\'es, 
robustes et bon march\'es, qui coop\'erent entre eux pour l'aider dans ses activit\'es de tous les jours. Des domaines d'application typiques sont la domotique et les 
r\'eseaux de capteurs. 
La r\'ealisation de ce paradigme informatique pr\'esente de nombreux d\'efis techniques \`a relever : multiplication des interfaces, importance du volume de donn\'ees \'echang\'ees, 
gestion du caract\`ere ad hoc du r\'eseau form\'e par les composants, etc. 
Les technologies P2P, en tant que paradigme de distribution de contenu \`a grande \'echelle et de plateforme de communication sur Internet, pr\'esentent de nombreux atouts 
pour y r\'epondre, comme l'illustrent les r\'ecents travaux dans le domaine \cite{braun08up2p,hu08hybrid}. 
Entre autres, la probl\'ematique de d\'ecouverte de services au sein d'un r\'eseau ubiquitaire rejoint la probl\'ematique d'indexation et de localisation d\'ecentralis\'ee
 sur laquelle nous nous penchons. Pour ces raisons, l'\'etude de solutions d'index P2P \`a destination des r\'eseaux ubiquitaires nous semble poss\`eder 
un fort potentiel (\cite{krco05enabling} en offre un exemple). 

% Le \emph{grid/cloud computing} est pr\'esent\'e avec l'informatique ubiquitaire comme l'un des deux axes majeurs du d\'eveloppement de l'informatique dans les ann\'ees \`a venir.
% Pour  >>g\'erer >> la multiplication des interfaces d'une part et l'augmentation \`a flux constant du volume de donn\'ees \'echang\'es d'autre part, on aura \`a la fois besoin d'une 
% offre de stockage en ligne gigantesque, et d'une miniaturisation permettant d'emporter (ou de rapatrier) partout avec soi le minimum de donn\'ees  >>n\'ecessaires >>.\\

\paragraph{Plateformes de << cloud >>}
Le << cloud computing >> est pr\'esent\'e avec l'informatique ubiquitaire comme l'un des deux axes majeurs du d\'eveloppement de l'informatique dans les ann\'ees \`a venir.
Le << cloud computing >> d\'esigne dans son acceptation la plus large une infrastructure permettant la mutualisation des ressources (capacit\'es de calcul ou stockage) d'ordinateurs 
\`a une (tr\`es) grande \'echelle. En tant que tel, le concept de << cloud computing >> peut \^etre reli\'e \`a celui de r\'eseau P2P, lequel mutualise les ressources
de serveurs utilisateurs pour des t\^aches allant du calcul parall\`ele au partage de fichiers. Toutefois la similitude s'arr\^ete l\`a. 
Les plateformes de << cloud >> commerciales s'accompagnent d'un mod\`ele \'economique de type location : l'<< Elastic Compute Cloud >> ou EC2 d'Amazon \cite{ec2} comme l'App Engine de 
Google \cite{appengine} proposent \`a la location un bouquet de services (capacit\'e de calcul, de stockage, interrogation des donn\'ees, etc.) 
accessibles \`a travers des interfaces Web. Les avantages pour l'entreprise cliente comprennent 
%: flexibilit\'e de la solution, absence de client logiciel \`a installer localement, externalisation des besoins informatiques, facturation \`a l'usage, 
le passage \`a l'\'echelle incr\'emental et les garanties de qualit\'e de services (disponiblit\'e, s\'ecurit\'e, etc.). 
Le << cloud computing >> h\'erite du << grid computing >> pour l'architecture d'informatique distribu\'ee, de l'<< utility computing >> pour le mod\`ele \'economique, et de 
l'<<\~ autonomic computing >> pour l'aspect auto-organisationnel. Mais sa sp\'ecificit\'e est dans la r\'ealisation du paradigme informatique orient\'e service 
(aussi d\'esign\'e par la terminologie *aaS : IaaS (<< Infrastructure As A Service >>), PaaS (<< Platform As A Service >>), SaaS (<< Software As A Service >>), etc.). 
Cette sp\'ecificit\'e distingue aussi les syst\`emes d'h\'ebergement en mode <<\~ cloud >> 
des syst\`emes P2P. M\^eme si la version courante de l'entr\'ee << cloud computing >> dans Wikipedia \cite{wiki-cloud}
fait l'amalgame, il serait peut \^etre plus correct de parler de compl\'ementarit\'e. L\`a o\`u les << cloud >> en production exploitent des datacenter, 
les r\'eseaux P2P populaires tels que BitTorrent, Seti@Home ou Skype f\'ed\`erent des serveurs utilisateurs reli\'ees par des connexions 
au d\'ebit inf\'erieur de plusieurs ordres de grandeur compar\'e aux liens IP des datacenter.
Le << cloud >> \'etant administr\'e, il offre une qualit\'e de service garantie, par opposition au service de niveau g\'en\'eralement \emph{best-effort} des r\'eseaux P2P. 
Par ailleurs, la connectivit\'e Internet des datacenter est plus avantageuse pour les applications impliquant le transfert entre les n\oe uds de gros volumes de donn\'ees. 
Les syst\`emes P2P, \`a leur tour, disposent du parc de ressources virtuellement illimit\'ees des 
utilisateurs d'Internet, sans leur imposer une d\'elocalisation de leurs donn\'ees chez les h\'ebergeurs \cite{stallman-cloud}. 
En conclusion, et pour faire le lien entre les index distribu\'es et les plateformes de << cloud >> : celles-ci constituent typiquement le genre d'infrastructure sur 
laquelle ex\'ecuter un index distribu\'e : con\c cues pour allouer des ressources \`a la demande aux applications h\'eberg\'ees, les plateformes de << cloud >> 
permettent d'approvisionner ces applications, dont le passage \`a l'\'echelle incr\'emental est constitutif du cahier des charges 
(valable pour les index de type \emph{distributed data stores}, abord\'es en \ref{basedonnees-dds-bds}, ou P2P).
D'ailleurs, les plateformes d'Amazon et de Google pr\'ec\'edemment cit\'ees incluent chacune dans leur offre de services un index bas\'e sur des solutions propri\'etaires : 
SimpleDB bas\'e sur Dynamo \cite{decandia07dynamo} 
(et combin\'e au service de stockage S3) pour l'EC2 d'Amazon, et Map Reduce \cite{dean08mapreduce} pour Google App Engine. Ces services pr\'esentent des objectifs tr\`es similaires
\`a ceux affich\'es par les index structu\'es P2P. C'est pourquoi Dynamo est d\'etaill\'e en \ref{basedonnees-dds-bds}. 

\paragraph{Content Delivery Network}
Un r\'eseau de distribution de contenu ou CDN (<< Content Delivery Network >>) est un r\'eseau de serveurs (proxy et proxy caches) 
permettant d'acc\'el\'erer et fluidifier l'acc\`es \`a certains services tr\`es sollicit\'es, 
notamment lors d'\'ev\`enements particuliers (<< flash crowds >>). 
%Pour cela, un r\'eseau de serveurs Web (serveur proxy et proxy cache) r\'epartis g\'eographiquement, 
%qui coop\'erent afin de mettre \'a disposition de mani\`ere efficace du contenu \`a des utilisateurs (souvent du contenu multim\'edia, volumineux).
L'approche consiste \`a multiplier et \`a r\'epartir g\'eographiquement de mani\`ere strat\'egique des serveurs, et \`a assurer le re-routage des acc\`es vers 
le serveur le plus pertinent\footnote{La pertinence \'etant d\'efinie selon une fonction multicrit\`ere, d'apr\`es la distance r\'eseau \`a l'utilisateur, la qualit\'e de la connexion \`a l'utilisateur, sa disponibilit\'e, etc.}. 
%ainsi qu senseibilit\'e moindre \`a la congestion r\'eseau ou aux pannes). 
L'objectif poursuivi est une meilleure exp\'erience utilisateur (minimisation du temps de t\'el\'echargement) et une r\'eduction des co\^uts de bande passante gr\^ace \`a la mise en cache.
 Une bonne description du fonctionnement d'un CDN est donn\'ee par Akamai dans \cite{dilley02globally}. 
%Les clients du CDN sont des FAI ou des fournisseurs de contenu qui souhaitent fiabiliser leur disponibilit\`e.
M\^eme si le P2P n'est pas la technologie adopt\'ee par tous les CDN, il est de plus en plus utilis\'e dans le transport
du contenu aux utilisateurs finaux. M\^eme si un r\'eseau P2P g\'en\`ere en mode nominal davantage de trafic r\'eseau que les CDN traditionnels bas\'es client-serveur 
(parce qu'un pair \'echange des donn\'ees dans les deux sens), il montre toute son int\'er\^et lors des << flash crowds >>, expression qui d\'esigne  
un pic soudain de f\'equentation sur un site Web, li\'e \`a la mise en ligne d'un contenu particuli\`erement populaire
%ph\'enom\`ene d'acc\`es dans un court intervalle de temps et par un grand nombre de personne \`a un contenu en ligne particulier 
(dernier correctif/mise-\`a-jour d'un logiciel r\'epandu ou du dernier \'episode d'une s\'erie t\'el\'evis\'ee \`a la mode, article portant sur 
une actualit\'e br\^ulante ou information en temps r\'eel, etc.) et qui n\'ecessite typiquement un CDN pour absorber le pic de charge et \'eviter que les serveurs ne tombent. 
Certains protocoles P2P tirent justement profit de la fr\'equence de t\'el\'echargement d'un contenu, accroissant d'autant leur efficacit\'e. 
CoopNet \cite{padmanabhan02case} est un exemple d'application de tels protocoles P2P par un CDN 
%permet de r\'eduire significativement ses co\^uts de connexion par rapport aux techniques traditionnelles, pour un m\^eme volume de donn\'ees distribu\'ees. 
% Un exemple est donn\'e par CoopNet \cite{padmanabhan02case}, issu des laboratoires de Microsoft Research. L'objectif de CoopNet est d'am\'eliorer les 
% performances d'applications client-serveur dans des cas de figure typiquement rencontr\'es au sein de CDN (le cas des << flash crowds >> est sp\'ecifiquement vis\'e). 
L'originalit\'e de l'approche r\'eside dans l'utilisation de techniques P2P en compl\'ementarit\'e avec les techniques de communication client-serveur : le r\'eseau P2P
entre en jeu pour contribuer \`a la distribution de contenu uniquement en cas de probl\`eme de congestion des serveurs. 

Pour conclure, les probl\'ematiques de qualit\'e de service et de s\'ecurit\'e, talons d'achille des r\'eseaux P2P,
 sont abord\'ees par le consortium P2P-Next \cite{p2pnext}, qui se consacre au d\'eveloppement des CDN bas\'es P2P.  
% On the other hand, the  >>long tail >> type material does not benefit much from P2P delivery schema, since, to gain advantage over traditional distribution models, a P2P-enabled CDN must 
% force storing (caching) data on peers' something that is usually not desired by users and which is rarely enabled.
% Contrary to popular belief P2P is not limited to low-bandwidth audio-video signal distribution. There is no technical boundary, built-in inefficiency, or flaw-by-design in peer-to-peer 
% technology to prevent distribution of full HD audio+video signal at, for example, 8 Mbit/s. It's just environmental factors, like low (upload) bandwidth or inadequate computing power in 
% CE devices, that prevent HD material being publicly available in P2P CDNs. (Low bandwidth problems also apply to traditional CDN, though.)
% There are some concerns about lack of Quality of Service control over P2P distribution, but these are being addressed by the P2P-Next consortium. Other concerns include security (e.g. 
% modification of content to include malware)and DRM.

\paragraph{Structures de donn\'ees passant \`a l'\'echelle}
Witold Litwin \cite{litwin93lh*, litwin94rp*, litwin96lh*} montre que les nouvelles exigences des architectures massivement parall\`eles
ne peuvent \^etre satisfaites par le choix de structures de donn\'ees traditionnelles. 
En effet, celles-ci se heurtent \`a des limitations comparables \`a celles rencontr\'ees par les bases de donn\'ees 
(cf. \ref{basedonnees-dds-bds}) : existence de goulots d'\'etranglement, 
manque de passage \`a l'\'echelle, absence de support pour la gestion de requ\^etes parall\`eles, etc. 
Abordant la probl\'ematique sp\'ecifique des structures de donn\'ees pour la gestion d\'ecentralis\'ee \`a large \'echelle de fichiers, 
Litwin introduit donc en 93 une nouvelle classe de structures de donn\'ees : les SDDS (de l'anglais, << Scalable Distributed Data Structures >>). 
Il propose un premier sch\`eme bas\'e sur du hachage, appel\'e LH* \cite{litwin93lh*}, 
puis un autre bas\'e sur les arbres B+ \footnote{L'arbre B \cite{bayer71binary} -\`a ne pas confondre avec l'arbre binaire- est 
un arbre \'equilibr\'e dont la caract\'eristique est de permettre aux n\oe uds 
de poss\'eder plus d'une cl\'e. L'arbre B+ diff\`ere l\'eg\`erement de l'arbre B, en ceci que toutes les donn\'ees sont stock\'ees exclusivement dans les feuilles.
L'arbre B+ conserve l'efficacit\'e des op\'erations de recherche et d'insertion des arbres B mais am\'eliore beaucoup l'efficacit\'e de la recherche du suivant 
( $O(log(n)$ pour les arbres B et $O(1)$ pour les arbres B+).}
 baptis\'e RP* \cite{litwin94rp*}, permettant les requ\^etes par plages de valeurs. 
D'autres exemples de SDDS bas\'es sur du hachage sont \cite{devine93design,vingralek94distributed} et \cite{kroll94distributing,kroll95balanced} sur des arbres B+.
Enfin, bas\'e sur les arbres k-d \cite{samet90design}, \cite{litwin95k-rp*s} g\`ere les recherches multi-attributs. 
%Enfin, \cite{karlsson00hqt*} offre un support efficace des donn\'ees spatiales () et des requ\^etes par plages de valeurs. 
  
L'ensemble des SDDS ont en commun les propri\'et\'es suivantes, qui font \'echo aux crit\`eres 1 et 2. : l'absence de point de centralit\'e (pas d'\'etat global maintenu) 
et rel\^achement des contraintes d'int\'egrit\'e sur les donn\'ees. 
A ce jour, peu d'applications des SDDS dans le domaine du P2P ont vu le jour, en d\'epit d'une convergence manifeste des deux domaines de recherche. 
Notons que les tables de hachage distribu\'ees, commun\'ement impl\'ement\'ees par des overlays P2P structur\'es (cf. \ref{subsec:Taxonomie g\'en\'erale des overlays P2P}) 
peuvent d'ailleurs \^etre consid\'er\'ees commes des SDDS \cite{litwin08lh*rsp2p2}. 
%D'ailleurs Litwin \emph{\emph{\emph{et al.}}} consid\`erent les tables de hachage distribu\'ees, commun\'ement impl\'ement\'ees avec un overlay P2P, comme des SDDS  
Une extension de LH*, nomm\'ee LH*P2Prs, est d\'edi\'ee \`a l'environnement P2P \cite{litwin08lh*rsp2p2}, dont il traite sp\'ecifiquement les probl\'ematiques de volatilit\'e des pairs. 
Toutefois, au regard des besoins sp\'ecifiques de cette th\`ese, les recherches par cl\'e de LH*P2Prs ne satisfont pas aux crit\`eres 3 et 4 concernant l'expressivit\'e des recherches. 
Enfin, citons les r\'ecents travaux de recherche de du Mouza, Litwin et Rigaud \cite{mouza09large-scale}, o\`u une structure d'arbre distribu\'ee appel\'ee SD-tree est propos\'ee. 
SD-tree est d\'edi\'e \`a l'indexation et la localisation de gros volumes de donn\'ees spatiales (donn\'ees d\'ecrites par une structure g\'eom\'etrique : point, ligne, polygone, etc.).

\subsection{Syst\`emes de gestion de bases de donn\'ees} \label{basedonnees-dds-bds}

Les syst\`emes de gestion de bases de donn\'ees relationnelles (SGBDR) constituent la solution standard de gestion de donn\'ees. 
Si les probl\'ematiques d'indexation et de localisation y sont envisag\'ees sous un angle parfois antagoniste au notre, 
deux domaines d\'eriv\'es des SGBDR, les solutions de stockage de donn\'ees distribu\'ees (DDS)
et les bases de donn\'ees spatiales (BDS), ayant d\'evelopp\'e des approches et des outils compl\'ementaires \`a ceux des SGBDR, 
pr\'esentent une grande familiarit\'e avec l'approche P2P. 
%Ces deux domaines pr\'esentent une communaut\'e d'int\'er\^et avec les index P2P. 
La figure \ref{fig:sgbdr-dds-bds} montre les recouvrements entre les trois domaines. Les solutions de stockage de donn\'ees distribu\'ees se sont d\'evelopp\'ees en opposition aux SGBDR en se revendiquant comme la solution de passage \`a tr\`es grande 
\'echelle pour la gestion de donn\'ees dynamiques. Certaines d'entre elles adoptent pour ce faire des technologies P2P, 
convergeant ainsi vers notre approche. 

Les bases de donn\'ees spatiales sont une extension spatiale des SGBDR
%D\'edi\'ees \`a la manipulation de gros volumes de donn\'ees, de dimensionnalit\'e \'elev\'ee et de distribution potentiellement  
 et fournissent la majeure partie des structures de donn\'ees multidimensionnelles r\'e-utilis\'ees dans les index P2P s\'emantiques. 

\begin{figure}[!h]
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.5\textwidth]{fig/sgbdr-dds-bds.png}
		\caption{Situation des index P2P par rapport aux solutions de stockage de donn\'ees distribu\'ees
et aux bases de donn\'ees spatiales.}
	\label{fig:sgbdr-dds-bds}
\end{figure}

Nous pr\'esentons dans la suite les solutions de stockage de donn\'ees distribu\'ees 
puis de bases de donn\'ees spatiales. En particulier, nous situerons les \'el\'ements r\'e-utilis\'es par les  
index P2P et ce que peuvent apporter les index P2P en comparaison. 

\subsubsection{Des SGBD aux solutions de stockage de donn\'ees distribu\'ees}

Les caract\'eristiques des SGBD sont : l'ind\'ependance des donn\'ees (s\'eparation des pr\'eoccupations entre logique applicative et organisation des donn\'ees), 
la flexibilit\'e des requ\^etes SQL, une s\'emantique transactionnelle (propri\'et\'es ACID) et la compl\'etude des recherches.  
Appropri\'es pour des applications qui tirent un b\'en\'efice des propri\'et\'es offertes par un SGBD complet
sans toutefois p\^atir d'un contr\^ole centralis\'e (par ex., les syst\`emes d'information), les SGBD montrent leurs limites face au d\'eveloppement d'applications aux contraintes fortes de 
passage \`a l'\'echelle (applications Web 2.0 type e-commerce, r\'eseaux sociaux, jeux, etc.). 
%Ces contraintes remettent en question la philosophie  >>one size fits all >>  pron\'ee par les SGBD \cite{stonebraker05onesize} et appellent au d\'eveloppement de syst\`emes de gestion de donn\'ees d\'edi\'es, donnant la 
%priorit\'e au passage \`a l'\'echelle. Pour atteindre cet objectif, ces syst\`emes de stockage distribu\'es (nous ne parlons plus de
%bases de donn\'ees au sens propre du terme) sacrifient les garanties ACID des moteurs transactionnels et la richesse s\'emantique des langages de requ\^etes type SQL. 
Pour illustrer ces limites, parcourons le cycle classique de d\'eveloppement d'une application Web. Celui-ci commence par un serveur Web et une base de donn\'ees traditionnelle, 
centralis\'es sur un m\^eme serveur. Dans l'hypoth\`ese optimiste, l'affluence du site et donc le nombre de transactions client augmente. A partir d'un certain seuil de charge, 
l'acc\`es aux donn\'ees peut se r\'ev\'eler un goulot d'\'etranglement, surtout si celles-ci sont tr\`es dynamiques (entra\^inant
de nombreuses \'ecritures) ou que le syst\`eme est soumis \`a des requ\^etes client en rafales demandant des pages qui ne tiennent pas en m\'emoire (entra\^inant de nombreux acc\`es disque). 
La figure \ref{fig:relationNbTransactionsTempsReponse} illustre le probl\`eme de passage \`a l'\'echelle des SGBD.
% (cf. figure \ref{fig:relationNbTransactionsTempsReponse}) : 

% \begin{figure}[!h]
% 	\centering
% 	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
% 		\includegraphics[width=3cm]{fig/relationNbTransactionsTempsReponse.png}
% 		\caption{Augmentation logarithmique du temps de r\'eponse $R_t$ en fonction de la taille du SGBD $GB_s$ et du volume des transactions $T_x$ 
% %(adapt\'e de http://www.codefutures.com/database-sharding/)
% .}
% 	\label{fig:relationNbTransactionsTempsReponse}
% \end{figure}

\begin{floatingfigure}[option]{7cm}
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=3cm]{fig/relationNbTransactionsTempsReponse.png}
		\caption{Augmentation logarithmique du temps de r\'eponse $R_t$ en fonction de la taille du SGBD $GB_s$ et du volume des transactions $T_x$ 
%(adapt\'e de http://www.codefutures.com/database-sharding/)
.}
\label{fig:relationNbTransactionsTempsReponse}
\end{floatingfigure}

Deux strat\'egies se pr\'esentent alors pour continuer \`a assurer la disponibilit\'e des donn\'ees : le passage \`a l'\'echelle vertical ou le passage \`a l'\'echelle horizontal. 
La strat\'egie verticale consiste \`a augmenter les capacit\'es du syst\`eme en ajoutant toujours plus de ressources (CPU, m\'emoire, disque) aux 
serveurs en place. Mais c'est une solution co\^uteuse et limit\'ee par les performances elles-m\^emes born\'ees du mat\'eriel. 
%Second, with data-center networks getting faster, it's not only cheaper to access memory than disk, it's cheaper to access another computer's memory through the network.
La strat\'egie horizontale consiste \`a ajouter des serveurs et \`a distribuer les donn\'ees et des traitements sur l'ensemble du cluster ainsi form\'e. 
En d'autres termes, la strat\'egie horizontale 
est une partition des donn\'ees. Plus complexe techniquement, cette derni\`ere approche pr\'esente l'avantage d'\^etre meilleure march\'e et plus robuste, en introduisant 
de la redondance. Dans la suite, nous nous pla\c cons exclusivement dans l'hypoth\`ese horizontale.  

L'adoption d'un passage \`a l'\'echelle horizontal par augmentation du nombre de serveurs se heurte toutefois \`a un obstacle : 
le mod\`ele transactionnel classique se distribue mal \`a partir d'une certaine taille de r\'eseau. 
%le mod\`ele transactionnel classique et les garanties ACID communes dans l'univers 
%des SGBD sont difficiles \`a mettre en \oe uvre dans une architecture distribu\'ee sur un grand nombre de n\oe uds. 
Parmi les techniques de distribution de bases de 
donn\'ees, le mod\`ele Ma\^itre/Esclaves \cite{ozsu99principles} permet certes de r\'epliquer les donn\'ees mais 
% si necessite plus infos, cf. http://www.codefutures.com/database-sharding/
fait reposer sur le serveur Ma\^itre toute la charge des op\'erations d'\'ecriture, avec pour cons\'equence que le probl\`eme de passage \`a l'\'echelle est d\'eplac\'e 
sur le Ma\^itre. La technique du << sharding >> constitue l'\'etape suivante dans la distribution d'une base de
% si necessite plus infos, http://highscalability.com/unorthodox-approach-database-design-coming-shard
 donn\'ees. Le principe suit la r\`egle << diviser pour mieux r\'egner >>. Typiquement, une base de donn\'ees est divis\'ee en un ensemble de bases de donn\'ees ind\'ependantes de 
plus petite taille (les << shards >>). Un m\'ecanisme permettant d'acc\'eder aux donn\'ees depuis le bon << shard >> est alors n\'ecessaire. 
Un << shard >> est constitu\'e d'un sous-ensemble des donn\'ees, l'ensemble
des << shards >> formant une partition des donn\'ees initiales (en d'autres termes, les donn\'ees des << shards >> sont disjointes). 
Par-rapport \`a la base de donn\'ees d'origine, un << shard >> est plus rapide, plus simple \`a administrer et plus \'economique
en termes de serveur de base de donn\'ees. 
Toute la complexit\'e du mod\`ele r\'eside dans le choix d'une strat\'egie de partition : la conception des << shards >> est un probl\`eme difficile 
qui n'est pas automatisable et qui se repose \`a chaque \'evolution du sch\'ema de 
donn\'ees, \`a chaque \'evolution de la charge ou \`a chaque \'evolution du nombre de serveurs. En d\'enormalisant les tables pour passer \`a l'\'echelle, 
le << sharding >> pousse en quelque sorte le mod\`ele relationnel dans ses retranchements. 

Une fois la base de donn\'ees originelle r\'epartie sur des serveurs ind\'ependants, une bonne partie de la complexit\'e 
inh\'erente \`a la distribution des donn\'ees et des requ\^etes se trouve d\'eplac\'ee 
%\`a la p\'eriph\'erie du syst\`eme de stockage, 
au niveau applicatif. L'utilisateur doit s'interfacer et choisir une bonne partition, d\'eterminer pour chaque requ\^ete le << shard >>
concern\'e, g\'erer manuellement les requ\^etes join sollicitant plusieurs << shards >>, \ldots 
% Le \emph{sharding} repousse au niveau applicatif la complexit\'e inh\'erente \`a la distribution des donn\'ees et des requ\^etes. Une fois la base de donn\'ees
% originelle r\'eparties sur des serveurs ind\'ependants, il reste \`a charge de l'application cliente de fournir la glue n\'ecessaire (et de retoucher le code applicatif) : 
% la strat\'egie de partitionnement (selon des crit\`eres tels que l\'equilibrage de la charge des requ\^etes, \ldots), d\'termination pour chaque requ\^ete du << shard >>
% concern\'e, reconstruction des requ\^etes complexes, \ldots  

%TODO schema evolution bd : archi centralise -> deux serveurs + scaling vertical -> maitre/esclave + scaling horizontal -> sharding \\

La complexit\'e de ce processus de passage \`a l'\'echelle d'un SGBD, dont l'architecture n\'ecessite d'\^etre modifi\'ee en profondeur afin d'absorber la mont\'ee en charge applicative, 
provient du fait qu'un SGBD est par essence centralis\'e. En particulier, une coh\'erence forte est n\'ecessaire (propri\'et\'es ACID). 
La difficult\'e de concilier simultan\'ement au sein d'un m\^eme syst\`eme r\'esilience aux pannes, coh\'erence forte et haute disponibilit\'e a \'et\'e constat\'ee depuis longtemps 
dans le domaine des bases de donn\'ees r\'epliqu\'ees \cite{bernstein84algorithm} 
et formalis\'ee dans le th\'eor\`eme de Brewer (<< Consistency, Availability, Partition tolerance >> ou CAP) qui fut prouv\'e en 2002 par Gilbert et Lynch \cite{gilbert02brewer}.  
%qui stipule qu'au fur est \`a mesure qu'il passe \`a l'\'echelle, un syst\`eme distribu\'e ne peut satisfaire simultan\'ement les propri\'et\'es de coh\'erence forte, de disponibilit\'e et de 
%tol\'erance aux pannes (\emph{Consistency, Availability, Partition tolerance} ou CAP). 
% Cette difficult\'e a \'et\'e imput\'ee au caract\`ere mal adapt\'e du mod\`ele transactionnel \` la partition des donn\'ees en parties 
% ind\'ependantes, dont nous avons vu qu'il \'etait essentiel au passage \`a l'\'echelle 
Ce constat am\`ene \`a repenser la gestion de donn\'ees dans les syst\`emes distribu\'es au-del\`a des solutions 
traditionnelles de SGBD, dont le mod\`ele transactionnel rentre en conflit avec la partition des donn\'ees, essentielle au passage \`a l'\'echelle. Ce nouveau paradigme de conception des syst\`emes \`a grande \'echelle, 
parfois d\'esign\'ee en anglais comme << non-RDBMS >> ou m\^eme << noSQL >>, pr\^one la disponibilit\'e au d\'etriment de la coh\'erence dans les syst\`emes \`a grande \'echelle : 
concevoir des syst\`emes BASE (<< Basically Available, Soft state, Eventually consistent >>) \cite{pritchett08base}, par opposition \`a ACID. 
%Une approche alternative au probl\`eme impliquant un changement total de perspective est le concept de sys\`eme BASE (\emph{Basically Available, Soft state, Eventually consistent}) \cite{pritchett08base}. 
Le paradigme BASE est diam\'etralement oppos\'e au paradigme ACID. L\`a o\`u l'approche ACID est stricte et force la coh\'erence 
\`a l'issue de chaque op\'eration, l'approche BASE est laxiste et accepte que la coh\'erence de la base ne soit acquise qu'au bout d'un temps et d'un nombre d'op\'erations ind\'efini 
(Vogels parle de syst\`eme << eventually consistent >> dans \cite {vogels08eventually}). 
% weak consistency / optimistic / focus on availability / best effort / 

Ce changement de paradigme dans la gestion des donn\'ees fournit le cadre conceptuel aux travaux de cette th\`ese. Il est au fondement 
d'une nouvelle famille de solutions de \emph{stockage de donn\'ees distribu\'ees}, en anglais : << distributed data stores >> (d\'esign\'ees ci-apr\'es par leur acronyme DDS). 
Les DDS r\'epondent \`a des besoins sp\'ecifiques : 
\begin{itemize}
\item Besoin en passage \`a l'\'echelle : fort. Notamment, un objectif est le passage \`a l'\'echelle incr\'emental. Le syst\`eme doit \^etre
capable d'int\'egrer ou de rel\^acher de nouvelles ressources \`a la vol\'ee \footnote{Dans les faits, cette propri\'et\'e ne se v\'erifie par pour tous les DDS, parmi 
lesquels Tokyo Cabinet\cite{tokyocabinet}, Redis \cite{redis}, MongoDB \cite{mongodb}, etc. Il n'est pas possible d'ajouter \`a ces syst\`emes un serveur 
facilement et d'augmenter ainsi le d\'ebit des requ\^etes, sans passer par du << sharding >> c\^ot\'e client.} ;
\item Besoin en disponibilit\'e : fort (minimisation de la latence) ;
\item Besoin en expressivit\'e des requ\^etes : faible. Certains DDS sont plus expressifs que d'autres, comme Cassandra \cite{cassandra},
qui autorise des requ\^etes par intervalles de valeurs. Mais de mani\`ere g\'en\'erale, les DDS ne permettent pas - et ne visent pas non plus - une s\'emantique SQL ;
\item Besoin en coh\'erence : faible. Le choix de compromis fait par les DDS est de favoriser la r\'eactivit\'e aux d\'epens de la coh\'erence. Ce qui n'emp\^eche pas certaines solutions, 
comme Scalaris \cite{schutt08scalaris}, d'offrir des garanties ACID aux transactions, en utilisant au-dessus d'une DHT un algorithme de consensus.
\end{itemize}
\vspace{0.6cm}
% Ces besoins sont interd\'ependants : le passage \`a l'\'echelle incr\'emental, en favorisant des architectures distribu\'ees au couplage
% faible entre les composants, b\'en\'eficie aussi \`a la latence. De m\^eme, des contraintes de coh\'erence faibles diminuent la latence, en
% permettant qu'une mise-\`a-jour rende la main aussit\^ot, sans entra\^iner de processus de coordination entre multiples serveurs
% de bases-de donn\'ees, etc. 
%http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it

Les DDS ne sont pas des bases de donn\'ees : ils n'utilisent ni les mod\`eles de donn\'ees (notamment relationnel) ni les langages d'interrogation 
(comme SQL) caract\'erisant les bases de donn\'ees.
En lieu et place du mod\'ele de donn\'ees relationnel, les DDS proposent en g\'en\'eral \`a la r\'eplication et \`a la distribution les mod\`eles suivants : 
\begin{itemize}
\item Mod\`ele de donn\'ees de type documents. Exemple : MongoDB \cite{mongodb}
\item Mod\`ele de donn\'ees de type tables associatives multidimensionnelles. Exemple : BigTable \cite{chang06bigtable}
%, HBase \cite{hbase}, Hypertable \cite{hypertable}, \ldots
\item Mod\`ele de r\'eseau (\emph{network model}). Exemple : Neo4J \cite{neo4j}
\item Mod\`ele de donn\'ees de type valeur binaire. Exemples : Dynamo \cite{decandia07dynamo} et ses d\'eclinaisons open source Dynomite \cite{dynomite} et Voldemort \cite{voldemort}, Scalaris \cite{schutt08scalaris}, MemcacheDB \cite{memcachedb}, \ldots 
\end{itemize}
\vspace{0.6cm}
Le dernier cas correspond aux DDS de type cl\'e-valeur (en anglais \emph{key value stores}, parfois trompeusement d\'esign\'es en fran\c cais par << bases de donn\'ees >> de type cl\'e-valeur). 
Le service permet des op\'erations de lecture et d'\'ecriture sur des donn\'ees identifi\'ees de fa\c con unique par une cl\'e. 
%Les DDS de type cl\'e-valeur sont assimilables \`a des DHT (vues en \ref{}).
% Les tables de hachage distribu\'ees (ou DHT, pour \emph{Distributed Hash Table}) forment une famille de structures de donn\'ees d\'ecentralis\'ees, distribu\'ees sur un ensemble de n\oe uds : 
% elles sont fondamentales dans le domaine des index distribu\'es et tiennent une place importante dans la section suivante, traitant des index P2P. 
% Une DHT fournit un service similaire \`a une table de hachage : un ensemble de paires (cl\'e,valeur) sont stock\'ees sur un ensemble de n\oe uds et un n\oe ud quelconque peut 
% r\'ecup\'erer de mani\`ere efficace la valeur associ\'ee \`a une cl\'e donn\'ee. La correspondance entre cl\'es et valeurs est distribu\'ee au sein des n\oe uds de telle mani\`ere \`a 
% entra\^iner des mise-\`a-jour minimales lors d'une modification de l'ensemble
% des n\oe uds. Ces choix de conception conf\`erent aux DHT de bonnes propri\'et\'es de scalabilit\'e, de r\'esilience aux pannes et 
% d'adaptativit\'e \`a la volatilit\'e des n\oe uds (\emph{churn}). C'est pourquoi les DHT servent souvent de brique dans la construction 
% de services plus complexes, tels que des syst\`emes distribu\'es de fichiers, des services de noms de domaines ou encore des index P2P. La figure \ref{dht} sch\'ematise le fonctionnement
% g\'en\'eral d'une DHT et par extension des DDS de type cl\'e-valeur et notamment de Dynamo, pr\'esent\'e ci-apr\`es. 
% 
% \begin{figure}[!h]
% \centering
% \includegraphics[width=0.5\textwidth]{./fig/dht.png}
% % conception_generique_overlay_ang.png: 346x238 pixel, 72dpi, 12.20x8.40 cm, bb=0 0 346 238
% \caption{Fonctionnement g\'en\'eral d'une DHT (adapt\'ee de S. Krakowiac)}
% \label{dht}
% \end{figure}
% 
% %\item Limitations : %http://spyced.blogspot.com/2009/05/why-you-wont-be-building-your-killer.html#

Les DDS pr\'esentent un int\'er\^et particulier dans le cadre de nos travaux car ils peuvent \^etre consid\'er\'es comme le maillon entre le domaine des bases de donn\'ees et celui des index distribu\'es pair-\`a-pair. D'ailleurs, 
cetains DDS s'inspirent de protocoles P2P, tels que les algorithmes de Chord \cite{stoica01chord} pour Scalaris \cite{schutt08scalaris}. 
Le cas de Dynamo \cite{decandia07dynamo} nous permet d'illustrer les similitudes et les diff\'erences entre les approches DDS et P2P. 
%Con\c cus pour palier les limitations des bases de donn\'ees dans le cadre d'applications massivement distribu\'ees, 
%ils partagent avec l'approche P2P les caract\'eristiques suivantes : 
%(i) s'ex\'ecuter sur un tr\`es grand nombre de serveurs d'entr\'ee de gamme (\emph{commodity hardware}) ; 
%(ii) le passage \`a l'\'echelle horizontal incr\'emental ; 
%(iii)
%Les solutions de DDS d\'ecentralis\'ees ont en commun avec les overlays P2P structur\'es les points suivants : 
%\begin{enumerate}
%\item De supporter un mod\`ele de donn\'ees et un mod\`ele de requ\^etes simples 
%\item D'\^etre bon march\'e (ne se reposant pas sur une infrastructure mat\'erielle sp\'ecifique et/ou co\^uteuse)
%\item De passer \`a l'\'echelle horizontalement et incr\'ementalement 
%%\item D'\^etre auto-organisant (demandant peu d'administration)
%\item D'\^etre en coh\'erence faible (\emph{eventually consistent})
%\end{enumerate} 
%\vspace{.2cm}
Dynamo est une DHT utilis\'ee en interne par Amazon, dans la gestion de l'\'etat de services ayant des contraintes fortes en termes de latence. 
Un exemple typique d'un tel service est le << panier d'achat >> d'une application d'e-commerce. 
En tant que DHT, Dynamo ne supporte que les acc\`es par cl\'e primaire.
Ainsi, un ajout ou une suppression d'article dans un panier se traduit par des requ\^etes put() sur une instance de Dynamo. 
%Dynamo est pr\'evu pour indexer et localiser des objets de taille relativement faible (< 1M). 
A la mani\`ere des index P2P, Dynamo est con\c cu pour s'ex\'ecuter sur un tr\`es grand nombre de serveurs d'entr\'ee de gamme (<< commodity hardware >>). 
Autre point commun avec l'approche P2P : l'une des clauses principales du cahier des charges de Dynamo est le passage \`a l'\'echelle incr\'emental.
A cette fin, Dynamo utilise un m\'ecanisme de partition dynamique des donn\'ees sur un ensemble de serveurs (ou n\oe uds). 
Ce m\'ecanisme repose sur un algorithme de hachage homog\`ene \cite{karger97consistent}, qui permet de distribuer les donn\'ees de telle sorte \`a en
r\'epartir la charge sur les n\oe uds. Cette strat\'egie de placement des donn\'ees sur les n\oe uds est couramment
 utilis\'ee dans les index P2P (plus de d\'etails en \ref{sec:Etat de l'art : Conception dirig\'ee par le routage d'overlays P2P structur\'es}).
Dynamo applique une variante du hachage homog\`ene qui lui est sp\'ecifique (introduisant le concept de <<\~ n\oe ud virtuel >>), 
lui permettant de prendre en compte l'h\'et\'erog\'en\'eit\'e des capacit\'es des n\oe uds lors de la distribution des donn\'ees.
En ce qui concerne la coh\'erence des donn\'ees, Dynamo autorise que les modifications apport\'ees \`a une donn\'ee soient propag\'ees de mani\`ere 
asynchrone \`a tous ses r\'eplicats, ce qui est \'egalement l'usage dans les r\'eseaux P2P. 
Dans l'exemple du panier, la contrainte sur une modification de son \'etat est que la modification 
ne peut jamais \^etre perdue ou emp\^ech\'ee. Quand un client d\'esire ajouter ou supprimer un article de son panier et que la version la plus \`a jour 
de l'\'etat du panier n'est pas disponible, l'article est ajout\'e (resp. supprim\'e) dans l'ancienne version et les versions divergentes r\'econcili\'ees par la suite.
%Enfin, Dynamo ne se focalise pas sur les probl\'ematiques de coh\'erence des donn\'ees, ni de s\'ecurit\'e, \'etant d\'evelopp\'e pour un usage en environnement de confiance \footnote{Des solutions d'index P2P s'attachent \`a fournir des garanties de s\'ecurit\'e, mais ce n'est pas traditionnellement le c\o eur de cible des syst\`emes P2P}. 
Les similitudes sont donc nombreuses entre les DDS et les index P2P, aussi bien dans les objectifs poursuivis que les techniques employ\'ees. Toutefois des diff\'erences fondamentales 
demeurent. Le principal point de divergence r\'eside dans les contraintes de latence impos\'ees par les DDS (dans le cas d'Amazon, 
la contrainte est d'une r\'eponse retourn\'ee dans les 300ms pour 99,9\% des requ\^etes, pour un pic de charge de 300 requ\^etes/seconde). 
Ces contraintes se r\'epercutent sur le choix des protocoles de routage. Ainsi, les overlays P2P mettent en \oe uvre des protocoles multi-sauts qui peuvent entra\^iner des variations 
dans le temps de r\'eponse, ce que ne peuvent se permettre les DDS. Par opposition, les DDS se d\'efinissent comme des DHT << en un saut >>
(<<\~ one-hop DHT >>). Ainsi dans Dynamo, si n'importe quel n\oe ud peut servir de point d'entr\'ee \`a une requ\^ete,
chaque n\oe ud poss\`ede suffisamment d'informations pour transmettre une requ\^ete, quelle qu'elle soit, au n\oe ud stockant la
solution (forc\'ement unique, puisque l'on est dans le cas d'une requ\^ete par cl\'e). 
Or le routage en un saut requiert une connaissance globale du syst\`eme, ce qui contrevient \`a notre crit\`ere 1.  


%Pour conclure bri\`evement sur les DDS, les avantages et limitations techniques du mod\`ele recouvrent en grande partie ceux des solutions P2P d'index. Les avantages 
%comprennent l'extr\^eme passage \`a l'\'echelle et la capacit\'e \`a g\'erer l'arriv\'ee, le d\'epart ou les pannes continuelles de serveurs. 
%Les limitations portent sur la faible expressivit\'e des DHT. 
%La distinction se fait sur le niveau de d\'ecentralisation, plus faible chez les DDS. 
 
%http://en.wikipedia.org/wiki/Distributed_hash_table
%http://spyced.blogspot.com/2009/05/why-you-wont-be-building-your-killer.html

%Une table de hachage distribu\'ee (ou DHT, de l'anglais) fournit une solution int\'eressante pour le passage \'a l'\'echelle dans le stockage des op\'erations (Log)
%dans un systï¿½me P2P. Une DHT est une structure de donn\'ees d\'ecentralis\'ee qui associe une cl\'e \'a une ressource. Chaque cl\'e de la
%table est le r\'esultat d'une fonction de hachage appliqu\'ee \'a un
%\'el\'ement de la ressource, comme par exemple, son nom. La fonction de hachage garantit que pour deux ressources diff\'erentes,
%les cl\'es g\'en\'er\'ees le seront aussi. Ainsi, l'unicit\'e de la cl\'e permet
%d'identifier et de retrouver de mani\`ere fiable la ressource \'a
%laquelle elle est associ\'ee. Les op\'erations de base r\'ealisables sur
%les DHTs sont les op\'erations lookup(cl'e) et put(cl\'e,valeur),
%permettant respectivement de r\'ecup\'erer la valeur associ\'ee \`a la cl\'e
%et de stocker une cl\'e et sa valeur associ\'ee dans la table de hachage
%distribu\'ee. 

%\begin{itemize}
%% source scalabilite : http://bjclark.me/2009/08/04/nosql-if-only-it-was-that-easy/
%% source solutions : http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/
%\item Nombreuses solutions de DDS : Tokyo, Redis (http://code.google.com/p/redis/), Dynamo et ses clones Voldemort, Scalaris, Dynomite, Kai\ldots
%\item Certains DDS ne sont pas distribu\'es et ne passent pas \`a l'\'echelle incremental : Tokyo (http://tokyocabinet.sourceforge.net/), Redis (http://code.google.com/p/redis/)
%\item Les DDS qui passent \`a l'\'echelle : Cassandra , Amazon S3 (http://aws.amazon.com/s3/)
%\item Detailler Dynamo (http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf). 
%\begin{itemize}
%\item Mentionner implem open source Voldemort 
%%(http://highscalability.com/product-project-voldemort-distributed-database, http://randomfoo.net/2009/04/20/some-notes-on-distributed-key-stores
%%http://groups.google.com/group/project-voldemort/browse_thread/thread/685cc2623025c557?pli=1)
%\item Mentionner clones
%\item Comparer avec Scalaris
%\end{itemize}
%%Range queries: unlike most key/value stores, you can query for ordered ranges of keys.Cassandra is best thought of as a 4 or 5 dimensional hash. open-source
%% source cassandra : http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/
%\end{itemize}

\subsubsection{Des SGBD aux bases de donn\'ees spatiales} \label{subsubsec:Des SGBD aux bases de donn\'ees spatiales}
Les bases de donn\'ees spatiales (BDS) ont grandement inspir\'e et aliment\'e les index P2P s\'emantiques.
 %m\'ethodes d'acc\`es spatiales ou SAM (pour << Spatial Access Methods >>).
Elles sont une extension des syst\`emes de base de donn\'ees : en plus de la gestion du mod\`ele de donn\'ees et de 
requ\^etes relationnel, les BDS g\`erent nativement les donn\'ees et des requ\^etes \emph{spatiales}. 

Les donn\'ees spatiales sont initialement associ\'ees \`a des informations g\'eographiques, regroupant des donn\'ees sur la localisation, 
la forme et les relations entre espaces g\'eographiques. On peut g\'en\'eraliser la terminologie en englobant dans les 
donn\'ees spatiales l'ensemble des objets g\'eom\'etriques, dont les objets types sont les Point, Ligne, R\'egion. 
% Les donn\'ees spatiales sont index\'ees et localis\'ees par des syst\`emes de gestion de bases de donn\'ees particuliers 
% %\footnote{Le caract\`ere particulier des bases de donn\'ees
% %spatiales explique que nous ayions choisi de ne pas les ranger parmi les bases de donn\'ees traditionnelles, \'etudi\'ees dans la section \ref{basedonnees-dds-bds}}
% , appel\'ees \emph{bases de donn\'ees spatiales} (dont les syst\`emes d'information g\'eographiques ou SIG constituent 
% la sous-classe la plus commune). 
Une sp\'ecificit\'e des donn\'ees spatiales est leur caract\`ere \emph{multidimensionnel}, qui rend n\'ecessaire l'\'elaboration de techniques d'indexation sp\'ecifiques. 
En effet, les index unidimensionnels commun\'ement employ\'es en bases de donn\'ees (tel que l'arbre B et ses variantes) 
sont difficilement applicables au cas multidimensionnel, en l'absence de relation d'ordre total d\'efinissable sur un ensemble 
de donn\'ees multidimensionnelles, qui pr\'eserve la localit\'e spatiale. 

% %Revenons sur la r\'ef\'erence \`a un ordre bas\'e sur la s\'emantique. 
% Les requ\^etes par intervalles de valeurs ou de comparaison ont pour objet la recherche de donn\'ees corr\'el\'ees, ou proches s\'emantiquement. 
% Leur ex\'ecution est donc rendue plus efficace 
% lorsque la localit\'e s\'emantique de ces donn\'ees est pr\'eserv\'ee par la proc\'edure d'indexation : informellement, deux donn\'ees consid\'er\'ees comme proches (en termes de s\'emantique)
% sont alors stock\'ees par l'index dans un voisinage proche (en termes de distance de communication). Autrement dit, 
% lorsque la localit\'e s\'emantique des donn\'ees est pr\'eserv\'ee, la recherche dans l'index de donn\'ees proches s\'emantiquement se ram\`eme alors \`a une
% recherche dans un espace. L'\'etude de l'existant \`a venir s'attache donc plus particuli\`erement aux solutions d'index pr\'eservant un ordre sur les donn\'ees, ainsi qu'\`a 
% l'\'etude de la corr\'elation entre les caract\'eristiques d'un ordre et les fonctionnalit\'es de recherches qui en d\'ecoulent. 


% Les m\'ethodes d'acc\`es multidimensionnelles se classent en deux familles \cite{gaede98multidimensional}. La premi\`ere regroupe 
% les approches reposant sur les m\'ethodes d'acc\`es aux points (PAM, pour << Point Access Methods >>), et est repr\'esent\'ee 
% par les fichiers de grille\cite{} et les arbres KDB\cite{}. La seconde regroupe les approches utilisant des m\'ethodes d'acc\`es spatial (SAM, pour << Spatial Access Méthodes >>) 
% g\'erant des donn\'ees spatiales plus complexes, telles ques les lignes ou les polygones. Ces m\'ethodes sont illustr\'ees par les arbres R\cite{}s et ses d\'eriv\'es.  
% Les SAM sont d\'edi\'ees au traitement de requ\^etes spatiales, c'est-\`a-dire de requ\^etes portant sur des relations entre r\'egions de l'espace (intersection, inclusion, distance, etc.). 
Sont d\'esign\'ees par \emph{m\'ethodes d'acc\`es spatiales} ou SAM (pour << Spatial Access Methods >>), les structures de donn\'ees et 
algorithmes associ\'es d\'eploy\'es dans les bases de donn\'ees spatiales \cite{gaede98multidimensional}. 
Les m\'ethodes SAM utilisent des structures de donn\'ees particuli\`erement efficaces pour les requ\^etes d'intervalles ou de 
comparaison sur un grand volume de donn\'ees. 
%Trois familles de m\'ethodes sont pr\'esent\'ees ci-apr\`es : 
%Comme les SGBD classiques, les BDS sont centralis\'ees. De plus, l
%La sp\'ecificit\'e spatiale du mod\`ele de donn\'ees et de requ\^etes des BDS semble rendre les SAM incompatibles avec nos besoins. 
%Pourtant les mod\`eles se rejoignent. 
Or si l'on consid\`ere une restriction du mod\`ele de donn\'ees spatial aux donn\'ees de type Point (point dans un espace euclidien de dimension arbitraire), 
alors le mod\`ele de requ\^etes spatiales correspond au mod\`ele de requ\^etes expos\'e en \ref{sec:Mod\`ele de donn\'ees utilis\'e}. 
Prenons les exemples de deux types de requ\^etes spatiales : requ\^ete de point (<< point query >> ou PQ) et par fen\^etrage (<< window query >> ou WQ). 
\cite{gaede98multidimensional} en donne les d\'efinitions suivantes (on suppose que l'espace de repr\'esentation des donn\'ees est 
un espace euclidien de dimension $d$, $\mathcal{S}=E^d$) : 

\paragraph{D\'efinition (Requ\^ete de point)} : Etant donn\'e un point $p\in E^d$, trouver tous les objets $o$ qui 
ont une intersection non nulle avec $p$ : $PQ(p)=\left\{o\,/\,p\cap g(o)=p\right\}$

\paragraph{D\'efinition (Requ\^ete de fen\^etrage)} : Etant donn\'e un intervalle de dimension $d$, $I^d=\left\{[l_1,u_1]\times[l_2,u_2]\times\ldots\times[l_d,u_d]\right\}$, 
trouver tous les objets ayant au moins un point en commun avec $I^d$ : $WQ(I^d)=\left\{o|I^d\cap g(o)\neq 0\right\}$

\vspace{0.6cm}
D'apr\`es ces d\'efinitions, on observe que dans le cas particulier $g(o)\in E^d$, une requ\^ete de point revient \`a effectuer une requ\^ete exacte, et une requ\^ete par fen\^etrage 
\`a effectuer une requ\^ete par intervalles. Lorsque les donn\'ees spatiales consid\'er\'ees sont des points, on parle de
 m\'ethodes d'acc\`es aux points ou PAM, pour << Point Access Methods >>.  
De nombreuses m\'ethodes d'acc\`es multidimensionnelles existent pour la gestion de requ\^etes spatiales sur des points.   
Nous en d\'ecrivons ici bri\`evement deux, reposant sur des structures arborescentes, qui sont \`a la fois tr\`es populaires dans le domaine de 
l'indexation multidimensionnelle et qui ont inspir\'e les index P2P. 
Pour approfondir le sujet des donn\'ees spatiales, nous renvoyons 
aux \'etudes existantes, entre autres : \cite{frank91properties} pour une \'etude des propri\'et\'es 
et sp\'ecificit\'es des donn\'ees spatiales et \cite{guting94introduction} pour une introduction aux bases de donn\'ees spatiales.

\paragraph{Les arbres dans les bases de donn\'ees spatiales.} Le principe r\'egissant l'utilisation d'un arbre est la division ou partition hi\'erarchique
 de l'espace des donn\'ees (ou des attributs : il s'agit en g\'en\'eral d'un espace euclidien). 
Nous choisissons d'\'etudier deux cas d'arbre pour lesquels l'espace est d\'ecompos\'e \`a l'aide d'hyperplans de dimension $(d-1)$, iso-orient\'es et dont la direction alterne
entre les $d$ possibilit\'es. Le choix des hyperplans est guid\'e par la strat\'egie de partition : partition du jeu de donn\'ees ou bien partition de l'espace des donn\'ees. 
%Nous illustrons ces deux classes d'arbres en prenant deux exemples arch\'etypaux : l'arbre R et l'arbre quaternaire. 

%\paragraph{Partition du jeu de donn\'ees : l'exemple de l'arbre R}
Dans l'approche par \emph{partition du jeu de donn\'ees}, les donn\'ees sont regroup\'ees selon leur proximit\'e dans l'espace des attributs.
La solution la plus populaire de cette premi\`ere famille d'arbre est l'arbre R \cite{guttman84r-trees} (ou << R-tree >>, R pour Rectangle), 
dont un exemple en deux dimensions est donn\'e dans la figure \ref{fig:rtree}. 
L'arbre R est construit sur une hi\'erarchie de rectangles (ou hyper-rectangles)
% pour des dimensions sup\'erieures \`a 2)
 contenus les uns dans les autres. 
Le niveau le plus bas est constitu\'e des rectangles englobant minimaux\footnote{D\'efinition d'un rectangle englobant minimal ou MBR (<< minimal bounding rectangle >>) : 
Pour un ensemble de donn\'ees dans un espace de dimension quelconque, la bo\^ite englobante est 
l'hyper-rectangle d'hyper-volume minimum suffisant \`a contenir tous les points de l'ensemble.}
 : chaque feuille contient des entr\'ees de la forme $(oid, rect)$, o\`u $oid$ d\'esigne une donn\'ee et $rect$, le MBR.   
%(appel\'es \emph{bo\^ites englobantes}
Chaque n\oe ud interne contient des entr\'ees de la forme $(ref, rect)$ o\`u $ref$ est l'adresse d'un n\oe ud fils et $rect$ la bo\^ite englobante de toutes les entr\'ees
de ce fils. 
L'arbre R est une g\'en\'eralisation multidimensionnelle de l'arbre B. Ces deux arbres sont \'equilibr\'es, leur hauteur est logarithmique dans la taille du jeu de donn\'ees
et leur complexit\'e est lin\'eaire.
Les variantes de l'arbre-R incluent les arbres R+ \cite{sellis87r+-tree}, R* \cite{beckmann90r*-tree} et X \cite{berchtold96x-tree}.  
% SR \cite{katayama98sr-tree}, M \cite{ciaccia97m-tree}, TV \cite{lin94tv-tree} ou hB \cite{lomet90hb-tree}).   

% La version originelle de l'arbre R pr\'esente des d\'esavantages ayant motiv\'e l'\'etude de variantes plus efficaces. Notamment, 
% l'arbre R ne g\`erant que des rectangles englobant minimaux, il n'est pas indiqu\'e pour une r\'esolution efficace des requ\^etes exactes. De plus, les rectangles 
% pouvant se superposer, le parcours de plusieurs chemins depuis la racine est parfois n\'ecessaire pour isoler les rectangles pertinents. Par-ailleurs, la taille des rectangles
% peut influer sur les performances des requ\^etes par intervalle \cite{manolopoulos05r-trees}. Enfin, au-del\`a de dimensionnalit\'e \'egale \`a 2 ou 3, ses performances
% se d\'egradent rapidement, du

\begin{figure}[!h]
\centering
\includegraphics[width=\textwidth]{./fig/r-tree_g}
% Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
%\caption{Exemple d'arbre R en 2 dimensions (adapt\'e de \cite{coursenst})}
\caption{Exemple d'arbre R en 2 dimensions (via \cite{gaede98multidimensional}}
\label{fig:rtree}
\end{figure}

Dans l'approche par \emph{partition de l'espace des donn\'ees}, l'espace $\mathcal{S}$ est d\'ecoup\'e 
en un ensemble de cellules r\'eguli\`eres, selon des axes pr\'ed\'efinis, ind\'ependamment des clusters de donn\'ees. 
Chaque donn\'ee est alors associ\'ee \`a toutes les cellules qu'elle intersecte. 
% Dans un espace \`a $d$ dimensions, l'espace est d\'ecoup\'e ??????
%  hyperplan de directions perpendiculaire \`a $k$, une des dimensions. 
% A chaque division, la direction de l'hyperplan change en parcourant dans un ordre les $d$ dimensions. 
% A chaque niveau de l'arbre, les donn\'ees sont r\'eparties en fonction de la coordonn\'ee $k$ : toutes les donn\'ees de dimension $k$ inf\'erieure  
Un exemple arch\'etypal en est l'\emph{arbre quaternaire} (ou << quadtree >>), d\'evelop\'e par Finkel et Bentley en 1974 \cite{finkel74quadtree} et repris depuis
dans des centaines de travaux (pour une \'etude compl\`ete des diff\'erents types de quadtree et leurs applications : \cite{samet84quadtree}).
 %, dans lequel l'espace $\mathcal{S}$ est d\'ecoup\'e en un ensemble de cellules r\'eguli\`eres. Chaque donn\'ee est alors associ\'ee \`a toutes les cellules qu'elle intersecte. 
Dans le quadtree, chaque n\oe ud interne poss\`ede quatre fils. Chaque n\oe ud dans l'arbre est associ\'e \`a une cellule ou rectangle (hyper-rectangle en dimension sup\'erieure \`a 2). 
Les rectangles sont issus de la partition de l'espace en quadrants. Les quadrants des fils d'un m\^eme p\`ere forment une partition du rectangle du p\`ere. 
Lorsqu'une cellule est satur\'ee en donn\'ees, elle se divise r\'ecursivement en quatre cellules (d'autres exemples de m\'ethodes sont les grilles pour 
le stockage de donn\'ees ou << grid files >> \cite{nievergelt81grid} et les arbres K-D-B \cite{robinson81k-d-b-tree}). 


\begin{figure}[!h]
\centering
\includegraphics[width=\textwidth]{./fig/quadtree_g}
% Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
%\caption{Exemple d'arbre R en 2 dimensions (adapt\'e de \cite{coursenst})}
\caption{Exemple d'arbre quaternaire en 2 dimensions (via \cite{gaede98multidimensional})}
\label{fig:quadtree}
\end{figure}

\paragraph{}Pour une \'etude plus compl\`ete des diff\'erents types d'arbres, nous renvoyons aux travaux \cite{knuth98art, gaede98multidimensional}.
Ces m\'ethodes ont \'et\'e d\'evelopp\'ees dans un contexte centralis\'e. 
La section \ref{sec:Etat de l'art : Conception dirig\'ee par les donn\'ees d'overlays P2P structur\'es}
montre comment elles ont \'et\'e adapt\'ees \`a un contexte d\'ecentralis\'e pour les solutions d'index P2P. La discussion sur les 
avantages et limitations de ces techniques est \'egalement report\'ee en \ref{sec:Etat de l'art : Conception dirig\'ee par les donn\'ees d'overlays P2P structur\'es}. 

\subsubsection{Discussion}
%\begin{itemize}
%\item TODO tableau recapitulatif des DDS : 
Reprenant les crit\`eres \'edict\'es plus haut section \ref{sec:Grille d'\'evaluation ad hoc}, le tableau ci-dessous r\'esume les propri\'et\'es des solutions
d'index distribu\'es tangentes au P2P :  \\

% \begin{tabular}{|l|c|c|c|c|c|}
% \hline
% BD et  & D\'ecision \`a partir & Auto-scaling & Sym\'etrie & Support natif & Support natif \\
%  affili\'es & d'informations &  &  & des donn\'ees multi-  & de requ\^etes \\
%  & locales &  &  & dimensionnelles & complexes \\
% 
% \hline
% \hline
% SGBDD & Non & Non & Non & Oui & Oui \\
% \hline
% Sharding & Non & Non & Non & Oui & Pas jusqu'au  \\
% & & & & & point des SGBD \\
% \hline
% DDS & Non & Oui & Oui & Possible & Possible \\
% \hline
% Bases de  & & & & & \\
% donn\'ees  & Non & Non & Non & Oui & Oui  \\
% spatiales & & & & & \\
% \hline
% \end{tabular} \\
% \vspace{0.6cm}

\begin{tabular}{|l|c|c|c|c|c|}
\hline
BD et  & D\'ecision \`a  & Auto-scaling &  Support natif & Support natif & Compl\'etude\\
 affili\'es & partir d'infor-\- & et &  des donn\'ees multi-  & de requ\^etes &\\
 & mations locales & sym\'etrie  & dimensionnelles & complexes &\\

\hline
\hline
SGBDD & Non & Non & Oui & Oui & Oui\\
\hline
Sharding & Non & Non & Oui & Pas jusqu'au & Oui \\
& & & & point des SGBD &\\
\hline
DDS & Non & Oui & Possible & Possible & Oui \\
\hline
Bases de  & & & & & \\
donn\'ees  & Non & Non & Oui & Oui & Oui \\
spatiales & & & & & \\
\hline
\end{tabular} 
\captionof{table}{Tableau r\'ecapitulatif des solutions connexes d'index distribu\'ees}
\label{Tableau r\'ecapitulatif des solutions connexes d'index distribu\'ees}
\vspace{0.6cm}

En conclusion de cette section, malgr\'e des recouvrements avec nos objectifs, 
aucune des approches abord\'ees ne permet de satisfaire int\'egralement les contraintes fix\'ees. 

Ce chapitre se poursuit par une \'etude de l'approche orient\'ee pair-\`a-pair. L'objectif est double : 
comprendre ce que des index P2P apportent en comparaison des solutions d'index envisag\'ees pr\'ec\'edemment, et 
souligner les limitations des solutions d'index P2P existantes en regard de nos cinq crit\`eres.
%, avec une attention particuli\`ere accord\'ee \`a la d\'ecentralisation des traitements et l'expressivit\'e de requ\^etes. 

\section{Introduction \`a l'approche P2P pour la conception d'index d\'ecentralis\'es} \label{sec:Pr\'eliminaires sur l'approche P2P pour la conception d'index d\'ecentralis\'es}
%\section{Etat de l'art : l'approche P2P pour la conception d'index d\'ecentralis\'es} \label{overlays}
% Cette section pr\'esente les travaux de recherche sur les index d\'ecentralis\'es issus du domaine des r\'eseaux pair-\`a-pair, auquel se rattache PosNet. 
% Elle n'a pas pour vocation d'\^etre une \'etude exhaustive du champ du P2P. Les syst\`emes P2P ont de nombreuses applications en-dehors du partage de ressources. 
% De plus, au sein m\^eme des syst\`emes de partage de ressources, il existe bien entendu de nombreuses probl\'ematiques d'indexation et de localisation : 
% allocation de ressources, administration multidomaines, s\'ecurit\'e, etc. Dans le cadre de cette dissertation, nous limitons notre \'etude 
% aux solutions relevant des crit\`eres \'etablis en \ref{sec:Grille d'\'evaluation ad hoc}. 
Cette section regroupe quelques pr\'e-requis sur le paradigme pair-\`a-pair et son utilisation dans la conception d'index. 
Elle d\'ebute par une pr\'esentation du paradigme et la d\'efinition d'un overlay P2P. 
Elle se poursuit par une d\'ecomposition du processus de conception d'un overlay P2P afin d'en d\'egager les choix techniques qui subordonnent les 
propri\'et\'es fonctionnelles et non-fonctionnelles des solutions \`a l'\'etude. 
Parmi ces choix techniques, la topologie de l'overlay (en d'autres termes, s'il est structur\'e, non-structur\'e ou semi-structur\'e) est d\'eterminante. 
L'\'etat de l'art qui suit est restreint aux solutions d'overlays structur\'es et semi-structur\'es. 


% L'\'etat de l'art qui suit, en \ref{sec:Etatdelart : Conception dirig\'ee par le routage d'overlays P2P structur\'es}, est 
% restreinte aux solutions d'overlays structur\'es et semi-structur\'es. 
% L'\'etat de l'art est d\'ecoup\'e en deux parties, afin de rendre compte de deux types d'approche : conception dirig\'ee par le routage et conception dirig\'ee par les donn\'ees. 


%De nombreuses \'etudes compl\'ementaires sont disponibles / TODO [kos00, RM06, MRPM08]

%\subsection{Paradigme P2P}
%
%\subsection{Conception g\'en\'erique d'un overlay P2P} \label{conception g\'en\'erique}
%TODO int\'egrer le formalisme \\
%La conception d'un overlay P2P implique plusieurs \'etapes, comportant chacune des choix d\'ecisifs. Le processus, que r\'esume la 
%figure \ref{}, peut \^etre d\'ecrit comme une succession de mise en correspondance [TODO mappings],
%l'objectif final \'etant d'associer \`a toute donn\'ee index\'ee l'adresse du n\oe ud qui l'h\'eberge (son adresse).  
%
%\begin{figure}[!h]
%\centering
%\includegraphics[width=0.8\textwidth]{./fig/conception_generique_overlay_ang_2.png}
%% conception_generique_overlay_ang.png: 346x238 pixel, 72dpi, 12.20x8.40 cm, bb=0 0 346 238
%\caption{TODO}
%\end{figure}
%
%Les diff\'erentes \'etapes g\'en\'eriques sont les suivantes : 
%\begin{itemize}
%	\item Ensemble des donn\'ees -> ensemble des solutions : Choix d'une repr\'esentation [TODO d'un espace de nommage] des donn\'ees ;
%	\item Ensemble des serveurs -> ensemble des n\oe uds : Choix d'un espace de nommage des n\oe uds. Dans ce qui suit, nous d\'esignons par $N$ le nombre de n\oe uds. Pour 
%plus de lisibilit\'e, les identifiants sont cod\'es sur log $mn$ bits (en g\'en\'eral, les algorithmes choisissent $N \gg m$ , de telle sorte \`a ce
%que l'espace de nommage ne soit pas totalement peupl\'e) ;
%	\item Ensemble des solutions -> ensemble des n\oe uds : Choix d'une strat\'egie de partitionnement, ou de placement des donn\'ees. 
%Une strat\'egie de partitionnement distribue l'espace des solutions ou l'ensemble des solutions $S$ sur l'ensemble des n\oe uds $N$. Elle supporte l'ajout ou la suppression 
%de solutions de $S$, ainsi que l'arriv\'ee ou le d\'epart de n\oe uds dans $N$ ;
%	\item Ensemble des n\oe uds x ensemble des n\oe uds -> ensemble des routes : Choix d'une strat\'egie de routage. Il doit y avoir une route entre toute paire de n\oe uds de $N$ . 
%\end{itemize}
%
%Aberer, Alima \emph{\emph{\emph{et al.}}} livrent une r\'eflexion comparable \cite{alima04framework, aberer05essence} avant de proposer 
%l'utilisation d'un arbre $k$-aire en tant que strat\'egie de routage d'un overlay structur\'e.
%
%Si ces \'etapes sont communes \`a l'\'elaboration de toutes les solutions d'overlay P2P, l'\'etude des solutions propos\'ees laisse appar\^itre que les auteurs adoptent 
%en g\'e\'eral deux angles d'attaque, qui sont en quelque sorte l'inverse l'un de l'autre : 
%\begin{enumerate}
%	\item \textbf{Approche dirig\'ee par le routage} : Une topologie logique des pairs est s\'electionn\'ee pour ses bonnes propri\'et\'es de routage. 
%En fonction de quoi, une strat\'egie de placement des solutions est \'elabor\'ee, de laquelle d\'ependra les types de requ\^ete support\'es par le syst\`eme ;
%	\item \textbf{Approche dirig\'ee par les donn\'ees} : Une structure de donn\'ees est s\'electionn\'ee ou bien \'elabor\'ee selon de bonnes propri\'et\'es de recherche. 
%En fonction de quoi, une strat\'egie de placement des solutions est \'elabor\'ee, de laquelle d\'ependra l'inter-connexion des n\oe uds. 
%Cette derni\`ere approche revient \`a distribuer une structure de donn\'ees sur les pairs.
%\end{enumerate}
%
% >> >> >> >> >> >> >> >>> inserer pt de vue http://ilpubs.stanford.edu:8090/581/1/2003-1.pdf avec 3 dim : autonomie, robustesse, efficacite ?
%
%
%De nombreuses taxonomies d'index distribu\'es et notamment d'overlay P2P sont propos\'ees dans la litt\'erature \cite{lua05survey, risson06survey, meshkova08survey}. 
%Notre classification se distingue toutefois de ces \'etudes en essayant de d\'epasser la dichotomie classique DHT/non DHT. Discriminant les solutions sur le seul crit\`ere 
%du hachage comme strat\'egie de placement, cette classification ne nous para\^it en effet pas offrir un cadre conceptuel totalement satisfaisant. Dans ce qui suit, nous
%\'etudions les solutions d'overlay P2P structur\'ees en fonction de l'un ou l'autre des angles d'attaque expos\'es ci-dessus. Dans chaque cas, 
%nous distinguons les structures employ\'ees. Pour chaque solution, les usages sont pr\'ecis\'es (mod`eles de donn\'ees et de requ\^etes support\'es), autorisant une 
%comparaison des avantages et limitations de chacune. Nous esp\'erons ainsi fournir au lecteur exigeant une vue 
%repr\'esentative, \`a d\'efaut de pouvoir \^etre exhaustive, des possibilit\'es offertes par le choix du paradigme P2P pour la conception d'index. 
%
%Pour des raisons de concision, nous nous limitons aux mod\`eles de donn\'ees et de requ\^etes dans le spectre de nos travaux : 
%requ\^etes exactes uni/multidimensionnelles, requ\^etes par plages de valeurs uni/multidimensionnelles, requ\^etes skyline, etc. [TODO fournir des pointeurs tout de m\^eme ?].     

%\subsection{Approche P2P}

\subsection{Le paradigme P2P}

 Les syst\`emes \emph{pair-\`a-pair} ou P2P (pour << peer-to-peer >>) sont des syst\`emes distribu\'es 
%bas\'es sur une architecture (<< shared nothing architecture >>) : 
%form\'es de serveurs connect\'ees entre elles (les \emph{pairs} ou encore \emph{n\oe uds}). 
form\'es de serveurs connect\'es entre eux (les \emph{pairs} ou encore \emph{n\oe uds}). Les serveurs sont capables de s'auto-organiser pour former
  un r\'eseau dans le but de partager des ressources (donn\'ees, cycles CPU, espace de stockage, bande passante\ldots). Ils sont 
capables de s'adapter \`a des pannes et \`a des arriv\'ees ou d\'eparts de n\oe ud fr\'equents tout en maintenant une disponibilit\'e et des performances
  du syst\`eme acceptables, sans faire appel \`a des connaissances globales \cite{androutsellis-theotokis04survey}.

% Le \emph{pair-\`a-pair} ou P2P (pour << peer-to-peer >>) est un paradigme issu de l'informatique distribu\'ee. L'infrastructure P2P comprend une architecture r\'eseau 
% distribu\'ee et des technologies associ\'ees (logiciels et protocoles de communication). 
Dans un r\'eseau pair-\`a-pair, les n\oe uds poss\`edent tous un r\^ole identique, les rendant \'egaux entre eux (d'o\`u le terme de \emph{pair}).
Chaque pair est consid\'er\'e \`a la fois comme un client et comme un serveur, \`a la fois fournisseur et consommateur de ressources.  
Ainsi chaque pair rend une partie de ses ressources (puissance de calcul, espace de stockage, bande passante, etc.) directement accessible aux autres pairs.  
De m\^eme, chaque pair peut coop\'erer avec d'autres pairs dans l'exploitation de 
leurs ressources, sans que cela n\'ecessite de proc\'edure de coordination centralis\'ee \cite{schoder03peer}. 
Une architecture distribu\'ee sym\'etrique est ce qui caract\'erise le paradigme P2P, par opposition au paradigme client-serveur
\footnote{Nous adoptons dans ce document une d\'efinition stricte du mod\`ele pair-\`a-pair n'incluant pas les syst\`emes centralis\'es tels que Napster.}. 

La conception de syst\`emes P2P, en tant que syst\`emes distribu\'es, doit int\'egrer des probl\'ematiques sp\'ecifiques parmi lesquelles : 
\begin{itemize}
 \item \emph{Co\^ut des communications} : En g\'en\'eral, le temps de calcul local est consid\'er\'e n\'egligeable devant les temps de communications ;
\item \emph{Connaissance partielle} : Un n\oe ud doit effectuer ses t\^aches avec une connaissance \emph{a priori} limit\'ee de l'\'etat global du syst\`eme. 
% Dans un syst\`eme
% centralis\'e ou s\'equentiel, la m\'emoire n'est acc\'ed\'ee que par un processeur unique et en particulier, elle n'est pas modif\'ee si ce processeur unique
% ne la modifie pas. En distirbu\'e, un n\oe ud ne contr\^ole que son propre \'etat.  
Notamment, un n\oe ud ne conna\^it en g\'en\'eral qu'un nombre restreint de l'ensemble des n\oe uds du syst\`eme ;
\item \emph{Asynchronisme} : Les messages envoy\'es d'un n\oe ud \`a un autre arrivent en un temps fini (en l'absence de faute) mais impr\'evisible. L'ordre
d'arriv\'ee des messages ne peut donc \^etre d\'eduit d'apr\`es leur ordre d'\'emission. Dans la pratique, les syst\`emes g\`erent des bornes inf\'erieures
et sup\'erieures de transmission des messages ; 
\item \emph{Non-d\'eterminisme} : Dans un cadre asynchrone, deux ex\'ecutions cons\'ecutives d'un m\^eme programme sur des entr\'ees identiques 
peuvent avoir des r\'esultats distincts.   
\end{itemize}
\vspace{0.6cm}
% Selon ces crit\`eres, Usenet et ARPANET peuvent \^etre classifi\'es parmi les r\'eseaux P2P, ce qui en fait une architecture historique 
% domaine des t\'el\'ecommunications \cite{fischbach05core}. Depuis, le d\'eveloppement d'Internet et les co\^ut d\'ecroissant d  

% Ces caract\'eristiques font du P2P une technologie adapt\'ee aux applications pr\'esentant des contraintes en terme de passage \`a l'\'echelle, 
% de robustesse, d'adaptabilit\'e \`a des n\oe uds volatiles, de co\^uts.  

Les domaines d'application du paradigme P2P sont nombreux : calcul parall\`ele (XtremWeb \cite{cappello05computing} ou Seti@home\cite{seti@home}) ;
t\'el\'ephonie par Internet (Skype \cite{skype}) ;
outils collaboratifs \cite{hauswirth05onp2p} ; 
messagerie instantann\'ee (Jabber \cite{jabber}) ;
diffusion de groupe \cite{amir00low} ; 
routage IP \cite{andersen01resilient} ou dans les r\'eseaux ad-hoc \cite{krop05establishing} ;
streaming multimedia \cite{shah07peer} ; etc.
La principale application P2P reste toutefois la distribution de contenu (multimedia ou autres), avec notamment les applications de partage de
  fichiers (BitTorrent \cite{bittorrent}, Gnutella \cite{ripeanu01peer}, Freenet\cite{freenet}, MojoNation\cite{mojonation}, etc.).
Dans cette th\`ese, nous nous int\'eressons plus particuli\`erement \`a l'utilisation de r\'eseaux P2P en tant qu'index distribu\'es, c'est-\`a-dire
en tant qu'infrastructures d'indexation et de recherche de ressources d\'ecentralis\'ees. 
%La figure \ref{infrastructure} repr\'esente une vue en couches d'un syst\`eme P2P tr\`es g\'en\'eral. Des couches les plus hautes aux plus basses : 
%
%\begin{enumerate}
%\item Couche communaut\'es virtuelles : Concerne typiquement les applications de r\'eseaux sociaux ou bien, pour reprendre l'exemple donn\'e
%dans l'introduction, Jamendo \cite{jamendo} avec son onglet << Communaut\'es >> proposant la participation \`a des groupes de discussion (forums). 
%Cette couche r\'eunit les fonctionnalit\'es parfois propos\'ees de cr\'eation de communaut\'es virtuelles autour d'une application P2P
%\item Couche Applicative : Regroupe toutes les fonctionnalit\'es sp\'ecifiques \`a l'application reposant sur un r\'eseau P2P pour le partage de ressources
%\item Couche P2P : Le r\'eseau P2P \`a proprement dit : r\'eseau logique de pairs, muni de protocoles de communication. 
%Dans la suite du document, nous parlerons \emph{d'overlay} 
%\item Couche r\'eseau : Assure l'acheminement des informations entre deux n\oe uds. Aussi d\'esign\'ee par le terme \emph{underlay}, par opposition \`a overlay. 
%\end{enumerate}
%
%\begin{figure}[!h]
%\centering
%\includegraphics[width=0.7\textwidth]{./fig/P2PenCouches.png}
%% conception_generique_overlay_ang.png: 346x238 pixel, 72dpi, 12.20x8.40 cm, bb=0 0 346 238
%\caption{Sch\'ema g\'en\'eral en couches des infrastructures P2P / TODO \`a adapter de \cite{fischbach05core}}
%\label{infrastructure}
%\end{figure}

Un r\'eseau P2P est un r\'eseau logique ou \emph{overlay}, construit au-dessus d'un r\'eseau physique. Dans la suite du document, nous nous int\'eressons uniquement
\`a ces deux couches. La figure \ref{overlay-underlay} reprend les couches n\textdegree 0 et 1 relatives resp. \`a l'underlay et l'overlay de la figure \ref{infrastructure}, en les d\'eveloppant. 

Formellement, soit un graphe de connectivit\'e $G=(V,E)$ repr\'esentant le r\'eseau de transfert (par exemple Internet) et un sous-ensemble $V' \subseteq V$ 
de ses sommets. Un overlay d\'ecrit une topologie logique, c'est-\`a-dire un graphe connect\'e orient\'e $G'$ d\'efini sur ce sous-ensemble $V'$. Dans $G'$, deux sommets 
$s$ et $s'$ de $V'$ sont voisins ssi $s$ connait l'adresse de $s'$ (et peut donc communiquer directement avec lui).  
 %dans lequel un arc $a \in A$ relie $s$ \`a $s'$ ssi $s$ connait l'adresse de $s'$ (et peut donc communiquer directement avec lui). 

Les overlays P2P sont des r\'eseaux logiques employ\'es dans de nombreux syst\`emes pour fournir une infrastructure logique de communication au-dessus d'un r\'eseau physique pr\'e-existant. 
Concernant ce r\'eseau physique, les protocoles P2P reposent en g\'en\'eral sur les protocoles TCP/IP. Chaque n\oe ud poss\`ede une adresse unique employ\'ee par les autres n\oe uds pour 
communiquer avec lui et chaque n\oe ud peut communiquer avec tout autre n\oe ud, sous r\'eserve qu'il connaisse son adresse. 

\begin{figure}[!h]
\centering
%\includegraphics[width=0.7\textwidth]{}
% conception_generique_overlay_ang.png: 346x238 pixel, 72dpi, 12.20x8.40 cm, bb=0 0 346 238
\caption{TODO topologie logique au dessus topologie physique /// Correspondance entre la couche r\'eseau ou underlay, et la couche P2P ou overlay}
\label{fig:Correspondance entre les la couche r\'eseau ou underlay, et la couche P2P ou overlay}
\end{figure}

\subsection{Conception g\'en\'erique d'un overlay P2P} \label{subsec:Conception g\'en\'erique d'un overlay P2P}

La conception d'un overlay P2P comprend une s\'erie de choix d\'ecisifs. Le processus, que r\'esume la 
figure \ref{conceptionOverlay}, peut \^etre d\'ecrit comme une succession de mise en correspondance,
l'objectif final \'etant d'associer \`a toute donn\'ee index\'ee le n\oe ud qui l'h\'eberge (typiquement son adresse).  

\begin{figure}[!h]
\centering
\includegraphics[width=0.8\textwidth]{./fig/conception_generique_overlay_ang_2.png}
% conception_generique_overlay_ang.png: 346x238 pixel, 72dpi, 12.20x8.40 cm, bb=0 0 346 238
\caption{TODO redessiner = citer source /// D\'ecisions de conception d'un overlay P2P}
\label{conceptionOverlay}
\end{figure}

Les diff\'erentes \'etapes g\'en\'eriques sont les suivantes 
\footnote{Aberer, Alima \emph{et al.} livrent une r\'eflexion comparable \cite{alima04framework, aberer05essence} avant de proposer 
l'utilisation d'un arbre $k$-aire en tant que strat\'egie de routage d'un overlay structur\'e.} : 
\begin{itemize}
	\item $g : \mathcal{O} \rightarrow \mathcal{S}$ : Choix d'une repr\'esentation des donn\'ees ;
	\item $f : \mathcal{N} \rightarrow \mathcal{V}$ : Choix d'un espace de nommage des n\oe uds ; 
% Dans ce qui suit, 
% nous d\'esignons par $N$ le nombre de n\oe uds (cardinal de $g\left\langle \mathcal{V} \right\rangle$). 
% Pour plus de lisibilit\'e, les identifiants sont cod\'es sur $m$ bits (en g\'en\'eral, les algorith mes choisissent $N \gg m$, 
% % de telle sorte \`a ce que l'espace de nommage ne soit pas totalement peupl\'e) ;

% 	\item $p : g\left\langle \mathcal{S} \right\rangle \rightarrow g\left\langle \mathcal{V} \right\rangle$ : Choix d'une strat\'egie de partition, ou de placement des donn\'ees. 
% Une strat\'egie de partition distribue l'ensemble des donn\'ees (images de $\mathcal{O}$ par $g$)
% sur l'ensemble des n\oe uds (images de $\mathcal{N}$ par $f$). Elle supporte l'ajout ou la suppression 
% d'objets de $\mathcal{O}$, ainsi que l'arriv\'ee ou le d\'epart de n\oe uds dans $\mathcal{N}$ ;
\item $p : g\left\langle \mathcal{O} \right\rangle \rightarrow f\left\langle \mathcal{N} \right\rangle$ : Choix d'une strat\'egie de placement des donn\'ees. 
Une strat\'egie de placement distribue l'ensemble des donn\'ees (images de $\mathcal{O}$ par $g$) sur l'ensemble des n\oe uds (images de $\mathcal{N}$ par $f$). 
Elle supporte l'ajout ou la suppression d'objets de $\mathcal{O}$, ainsi que l'arriv\'ee ou le d\'epart de n\oe uds dans $\mathcal{N}$ ;
	\item $r : g\left\langle \mathcal{N} \right\rangle \times g\left\langle \mathcal{N} \right\rangle \rightarrow \mathcal{R}$ : Choix d'une strat\'egie de routage
	($\mathcal{R}$ : ensemble des routes). Il doit y avoir une route entre toute paire de n\oe uds de $\mathcal{V}$ . 
\end{itemize}
\vspace{0.6cm}

% Dans la discussion qui suit, nous supposons que des syst\`emes \`a $N$ n\oe uds, avec des identifiants sur log $N$ bits ( 
% m\^eme si en pratique, les algorithmes utilisent typiquement des identifiants sur log $N'$ bits, avec $N'  >> N$, de telle sorte \`a ce que l'espace 
% des identifiants ne soit pas totalement peupl\'e). 
% Enfin, par abus de langage nous employons dans la suite du document les termes <<  donn\'ee >> et << n\oe ud  >> dans le sens de leur repr\'esentation dans un espace de nommage. 

\subsection{Taxonomie g\'en\'erale des overlays P2P} \label{subsec:Taxonomie g\'en\'erale des overlays P2P}

Il est d'usage de distinguer les architectures d'overlays P2P selon le caract\`ere d\'eterministe ou non du placement des donn\'ees sur les n\oe uds.
Les diff\'erentes classes d'architecture sont : non-structur\'ee, structur\'ee et semi-structur\'ee. 
Nous sp\'ecifions ces classes puis nous nous focalisons par la suite sur les seuls overlays structur\'es et semi-structur\'es, 
auxquels se rapportent PosNet.  

Dans la discussion qui suit, nous supposons que des syst\`emes \`a $N$ n\oe uds, avec des identifiants sur log $N$ bits ( 
m\^eme si en pratique, les algorithmes utilisent typiquement des identifiants sur log $N'$ bits, avec $N'  >> N$, de telle sorte \`a ce que l'espace 
des identifiants ne soit pas totalement peupl\'e). 
Enfin, par abus de langage nous employons dans la suite du document les termes <<  donn\'ee >> et << n\oe ud  >> dans le sens de leur repr\'esentation dans un espace de nommage. 

\paragraph{Overlay \emph{non-structur\'e} :} 
Un overlay est dit non-structur\'e si sa topologie est ad-hoc et le placement des donn\'ees ind\'ependant de la topologie. 
Un n\oe ud poss\`ede un voisinage mais ignore les donn\'ees que d\'etiennent ses voisins. La recherche de donn\'ees se fait en aveugle, typiquement 
selon des protocoles de type inondation, marche al\'eatoire ou recherche par anneaux croissants avec TTL (<< expanding-ring Time-To-Live search >>) \cite{lua05survey}. Chaque
pair visit\'e par une requ\^ete l'\'evalue localement en regard des ressources qu'il d\'etient. 

Les avantages de ce mod\`ele r\'esident dans : 
\begin{itemize}
\item La simplicit\'e de maintenance d'une structure al\'eatoire ;
\item L'absence de restriction quant \`a l'expressivit\'e des requ\^etes, qui peuvent \^etre de tous types ;
\item La flexibilit\'e totale et la robustesse qui en d\'ecoule : Le placement d'une donn\'ee sur un n\oe ud est libre et 
un n\oe ud est parfaitement autonome dans le choix de ses voisins et de la route \`a suivre. 
\end{itemize}
Les points faibles des r\'eseaux non-structur\'es sont :
\begin{itemize}
 \item Le (non) passage \`a l'\'echelle : Le co\^ut en termes de bande passante des protocoles de routage bas\'es sur l'inondation (incluant la transmission des requ\^etes de recherche, 
l'\'emission des r\'eponses, les PING, les PONG, etc.) les rend difficilement d\'eployables \`a une large \'echelle. 
Une solution courante est la restriction du nombre de sauts dans l'overlay autoris\'e par requ\^ete de recherche (application d'un TTL) ;  
\item L'incompl\'etude des recherches : Le TTL limite le nombre de messages, mais il en limite aussi la port\'ee. En cons\'equence de quoi,
 une donn\'ee peut \^etre index\'ee mais ne pas \^etre localis\'ee car situ\'ee trop loin du n\oe ud source de la requ\^ete\footnote{Dans un syst\`eme de partage de fichiers, 
le caract\`ere accessible (<< reachability >>) d'un fichier d\'epend beaucoup de sa popularit\'e. 
Plus un fichier est populaire et plus il a de chance d'\^etre partag\'e et donc dupliqu\'e dans le r\'eseau. Plus un fichier est dupliqu\'e et plus les chances sont \'elev\'ees 
qu'une recherche aboutisse dans la limite du TTL.}.
\end{itemize}

La plupart des solutions << en production >> s'\'eloignent du mod\`ele th\'eorique non-structur\'e. Par exemple Gnutella \cite{gnutella}, qui a fait l'objet 
de nombreuses propositions d'am\'eliorations (\cite{lv02canheterogeneity, chawathe03making, ganesan03yappers}). Les derni\`eres versions introduisent une hi\'erarchie \`a deux niveaux 
dans les n\oe uds du r\'eseau (illustr\'ee figure \ref{fig:superpeer}) dans le but de r\'eduire les co\^uts de communication. S'affranchissant du mod\`ele P2P << pur >>, 
\cite{superpeers} propose de diff\'erencier les pairs selon leur rapidit\'e (ceux poss\'edant le plus de CPU et de bande passante) et de d\'echarger les n\oe uds moins
performants sur les \emph{super-n\oe uds} (ou super-pairs) d'une partie des traitements et des communications r\'eseau. On peut voir cette architecture comme une hi\'erarchie d'overlays, ou bien encore une hybridation des approches 
client-serveur et P2P, faisant de certains pairs des serveurs pour d'autres pairs.   

%Les exemples d'index P2P non-structur\'es inclus Gnutella \cite{gnutella}, KaZaA \cite{kazaa}. 
\begin{figure}[!h]
\centering
\includegraphics[width=0.6\textwidth]{./fig/superpeers.png}
% Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
\caption{Architecture d'overlay (emprunt\'e \`a \cite{fotiadou08bitpeer}). 
%Un tore est engendr\'e par la rotation d'un cercle autour d'un autre cercle (adapt\'e de Wikipedia).
}
\label{fig:superpeer}
\end{figure}

\paragraph{Overlay \emph{structur\'e} :}
Les overlays structur\'es ont \'emerg\'e en r\'eponse aux probl\`emes de passage \`a l'\'echelle du mod\`ele non-structur\'e. Leur principe est d'imposer une organisation aux
n\oe uds et de lier le placement des donn\'ees \`a la topologie des n\oe uds. Les donn\'ees (ou les pointeurs sur ces donn\'ees) sont plac\'ees sur les n\oe uds et
la correspondance entre les donn\'ees et leur adresse est maintenue dans une table de routage distribu\'ee.  

Les overlays P2P structur\'es reposent sur une \emph{table de hachage distribu\'ee} ou DHT (pour <<\~ Distributed Hash Table >>). 
% Les DHT sont
%  une famille de structures de donn\'ees d\'ecentralis\'ees, distribu\'ees sur un ensemble de n\oe uds : 
% elles sont fondamentales dans le domaine des index distribu\'es et tiennent une place importante dans la section suivante, traitant des index P2P. 
Typiquement, une DHT expose une interface dot\'ee des primitives $inserer(cle,valeur)$ et $localiser(cle)$, o\`u $cle$ est un identifiant d'objet et $valeur$ son contenu. 
Chaque n\oe ud stocke un ensemble de valeurs correspondant \`a un ensemble cons\'ecutif (un intervalle) de cl\'es. 
Il connait par ailleurs un certain nombre d'autres n\oe uds, appel\'es ses \emph{voisins}. Les n\oe uds \'etant organis\'es selon une topologie pr\'ed\'efinie, les d\'ecisions
de routage s'appuient sur cette information pour diriger les recherches en permettant \`a un n\oe ud de choisir efficacement parmi ses 
voisins le n\oe ud suivant pour r\'esoudre une requ\^ete donn\'ee. 
Enfin, la correspondance entre cl\'es et valeurs est distribu\'ee au sein des n\oe uds de telle mani\`ere \`a 
entra\^iner des mise-\`a-jour minimales lors d'une modification de l'ensemble des n\oe uds (arriv\'ee ou d\'epart d'un n\oe ud). 

Ces choix de conception conf\`erent aux DHT de solides propri\'et\'es de passage \`a l'\'echelle, de r\'esilience aux pannes et 
d'adaptativit\'e \`a la volatilit\'e des n\oe uds (<< churn >>). C'est pourquoi les DHT servent souvent de brique dans la construction 
de services plus complexes, tels que des syst\`emes distribu\'es de fichiers, des services de noms de domaines ou encore les index P2P. La figure \ref{dht} sch\'ematise le fonctionnement
g\'en\'eral d'une DHT. 
La section \ref{sec:Etat de l'art : Conception dirig\'ee par le routage d'overlays P2P structur\'es} offre de nombreux exemples d'overlays structur\'es en DHT. 
%et par extension des DDS de type cl\'e-valeur et notamment de Dynamo, pr\'esent\'e ci-apr\`es. 

\begin{figure}[!h]
\centering
\includegraphics[width=0.5\textwidth]{./fig/dht.png}
% conception_generique_overlay_ang.png: 346x238 pixel, 72dpi, 12.20x8.40 cm, bb=0 0 346 238
\caption{TODO traduire /// Fonctionnement g\'en\'eral d'une DHT}
\label{dht}
\end{figure}

\paragraph{Overlay \emph{semi-structur\'e} :} 
Les overlays semi-structur\'es visent \`a combiner une partie de la flexibilit\'e et de la robustesse des overlays non-structur\'es, 
avec une partie de l'efficacit\'e et des garanties fournies par les overlays structur\'es. 

Dans un overlay semi-structur\`e, le placement des donn\'ees est le plus souvent d\'eterministe, mais la relation de voisinage des n\oe uds est 
g\'en\'eralement plus libre voire m\^eme incertaine. 
La gestion des tables de routage est donc plus complexe que dans le cas des overlays bas\'es DHT. 
Mais les avantages conf\'er\'es aux overlays semi-structur\'es sont multiples : 

\emph{Passage \`a l'\'echelle incr\'emental : } Pour un n\oe ud donn\'e, le nombre de ses voisins (son degr\'e) 
n'est pas enti\`erement pr\'e-d\'efini et il ne d\'epend pas forc\'ement de la taille de l'overlay. Le degr\'e
 peut \'evoluer dans le temps et deux n\oe uds n'ont pas forc\'ement le m\^eme nombre de voisins. 
Or, comme il a \'et\'e mentionn\'e pr\'ec\'edemment, le degr\'e des n\oe uds a une incidence directe \`a la fois 
sur le co\^ut de maintenance de l'overlay et sur les performances du routage. 
Ce couplage plus faible entre structure et routage permet donc au syst\`eme de moduler le \emph{compromis latence/degr\'e} 
selon ses besoins et la taille de l'overlay ;

\emph{H\'et\'erog\'en\'eit\'e des n\oe uds :} Pour un n\oe ud donn\'e, l'identit\'e de ses voisins n'est pas
enti\`erement pr\'e-d\'efinie, ce qui lui donne une certaine autonomie dans leur choix. Il lui est notamment possible 
d'appliquer des crit\`eres de pr\'ef\'erence (en termes de proximit\'e r\'eseau, CPU, bande passante, etc.) ;

\emph{Robustesse : } Une plus grande autonomie des n\oe uds accroit aussi la robustesse du syst\`eme, puisqu'en cas d'indisponibilit\'e d'un voisin, il est possible d'en s\'electionner un autre.

%Pour un n\oe ud donn\'e, ses voisins ne sont ni identifi\'es, ni quantifi\'es . 
%Ainsi un n\oe ud jouit d'une certaine autonomie dans le choix de ses voisins, ce qui lui permet 
%d'appliquer des crit\`eres de pr\'ef\'erence et de prendre en compte l'h\'et\'erog\'en\'eit\'e des n\oe uds (en termes d'\'eloignement g\'eographique, CPU, bande passante, etc.). 
%Cette autonomie accroit aussi la robustesse du syst\`eme, puisqu'en cas d'indisponibilit\'e d'un voisin, il est possible d'en 
%s\'electionner un autre. 
%Enfin, le degr\'e des n\oe uds n'est en g\'en\'eral ni fix\'e \`a l'avance 
%(le degr\'e ne d\'e pend pas forc\'ement de la taille de l'overlay), 
%ni fig\'e (deux n\oe uds n'ont pas forc\'ement le m\^eme nombre de voisins). 
%Or, comme il a \'et\'e mentionn\'e pr\'ec\'edemment, le degr\'e des n\oe uds a une incidence directe \`a la fois 
%sur la flexibilit\'e du syst\`eme (taille des tables de routage) et sur sa latence (taille des routes). 
%Ce couplage plus faible entre structure et routage permet donc au syst\`eme de moduler le compromis latence/degr\'e selon ses besoins. 
%Le routage d\'epend du sch\'ema de placement des donn\'ees (et non de la topologie comme dans un r\{eseau structur\'e). 
%Parmi les exemples : Freenet, Symphony, \cite{li05searching} et Phenix.

\paragraph{}Les exemples d'overlays semi-structur\'es sont relativement moins nombreux que dans le cas structur\'e. Nous d\'etaillons trois exemples : Symphony, Aurelia et Freenet. 

Dans Symphony \cite{manku03symphony}, les tailles des tables sont flexibles et peuvent \^etre modif\'ees en cours d'ex\'ecution
pour ajuster le compromis latence/degr\'e. 
Une partie des entr\'ees de la table est d\'etermin\'ee selon une distribution en loi de puissance. 
Inspir\'es par la structure petit-monde \cite{kleinberg00small-world}, les
auteurs \'etendent les r\'esultats de Kleinberg et montrent dans Symphony qu'avec $k=O(1)$ liens par n\oe ud, il est possible 
d'acheminer des requ\^etes exactes avec un latence moyenne de $O(\frac{1}{k}log^2n)$ sauts. 

Aurelia \cite{wu05aurelia} adapte la taille de la table de routage aux capacit\'es des n\oe uds. 
Potentiellement, un n\oe ud maximal qui b\'en\'eficie de plus de bande passante, de m\'emoire, de CPU ou de long\'evit\'e que les autres, 
peut \^etre connect\'e \`a l'ensemble des autres n\oe uds et devenir plus central dans l'index. Par ailleurs, le choix des voisins d\'epend de la
distribution des donn\'ees et par exemple un n\oe ud va choisir comme voisin le candidat supervisant le plus de donn\'ees\footnote{Cette vision globale
\'etant obtenue par des techniques statistiques de type \'echantillonage p\'eriodique.}. 

Dans Freenet \cite{freenet}, l'overlay en phase d'initialisation est non-structur\'e, et 
les requ\^etes sont achemin\'ees selon une progression par essai/erreur. 
L'overlay converge vers la structure voulue sur la base des r\'esulats des requ\^etes pr\'ec\'edentes\footnote{Lors d'une d\'ecision de routage, 
un n\oe ud favorise les n\oe uds lui ayant r\'epondu positivement \`a des requ\^etes similaires (les auteurs parlent d'<< emergent feedback effect >>).}. 

% De mani\`ere g\'en\'erale, les diff\'erentes g\'eom\'etries, dont celles d\'etaill\'ees ci-dessous, se valent au regard du compromis \'etat/efficacit\'e.
% C'est ainsi que Gummadi \emph{\emph{\emph{et al.}}} proposent dans leur \'etude \cite{gummadi03impact} de diff\'erentier les g\'eom\'etries de routage 
% non plus sur les crit\`eres d'\'etat ou d'efficacit\'e, mais sur celui de la \emph{flexibilit\'e}. 
% Les auteurs caract\'erisent la flexibilit\'e d'une g\'eom\'etrie comme le degr\'e de libert\'e dont dispose un n\oe ud 
% dans le choix i) de ses voisins, ii) des routes. Lors de la constitution et de la maintenance des tables de routage, la g\'eom\'etrie permet-elle
% \`a un n\oe ud de choisir ses voisins (par exemple en fonction de la proximit\'e) ou bien le choix est-il d\'eterministe ? Pour une table et une destination donn\'ees,
% la g\'eom\'etrie permet-elle \`a un n\oe ud de  choisir le prochain saut ? 

%TODO d\'evelopper sur le sujet de la robustesse. Les diff\'erents m\'ecanismes. Parmi les m\'ecanismes : la flexibilit\'e. 
\paragraph{Discussion}
Ces diff\'erentes classes d'overlays P2P peuvent \^etre consid\'er\'ees sous plusieurs angles. 

Une premi\`ere mani\`ere de comparer les overlays P2P est de les comparer selon leur compromis \emph{expressivit\'e / compl\'etude}.  
% L'antagonisme entre ces deux propri\'et\'es d'un index, expressivit\'e du langage de requ\^etes et compl\'etude des recherches ets relev\'e par 
% de nombreux auteurs. 
Beaumont, Kermarrec \emph{et al.} soulignent dans \cite{beaumont07voronet,beaumont07peer} l'antagonisme entre ces deux propri\'et\'es d'un index, expressivit\'e du langage de requ\^etes et 
compl\'etude des recherches. 
Ils opposent ainsi les solutions d'index non-structur\'ees permettant des recherches expressives au d\'etriment 
du taux de rappel, aux solutions structur\'ees qui inversement offrent peu d'expressivit\'e mais un taux de rappel 
optimal\footnote{Plut\^ot que de compl\'etude ou de rappel, les auteurs parlent d'exhaustivit\'e des recherches, dans le sens de l'exhaustivit\'e de l'ensemble 
des solutions retourn\'ees.}.

Selon les crit\`eres edict\'es en d\'ebut de chapitre, nous cherchons dans cette th\`ese \`a maximiser les deux propri\'et\'es en proposant un index retournant des
solutions exactes \`a des requ\^etes de haut niveau. 
 
%La diff\'erence entre ces classes de solutions r\'eside dans l'organisation des n\oe uds participant aux recherches. 
% Selon que cette organisation permet une coop\'eration efficace ou non, les garanties offertes sont plus ou moins fortes. 
% Ainsi, dans le cas des solutions d'index non exhaustives ou non d\'eterministes, le processus de recherche s'op\`ere << en aveugle >>, 
% en l'absence de toute hypoth\`ese sur l'organisation du syst\`eme. Cette approche a l'avantage de la simplicit\'e, mais n'offre que
%  des garanties statistiques, qui ne suffisent pas toujours.  
% A contrario, dans le cas de solutions exhaustives, le processus de recherche est guid\'e par les n\oe uds, 
% sur la base de connaissances d\'etenues sur d'autres n\oe uds. Ces aspects sont approfondis aux 
% sections \ref{sec:Etat de l'art : Conception dirig\'ee par le routage d'overlays P2P structur\'es} 
% et \ref{sec:Etat de l'art : Conception dirig\'ee par les donn\'ees d'overlays P2P structur\'es}.  

\paragraph{}Une autre mani\`ere de consid\'erer les overlays P2P est de les comparer selon leur degr\'e de \emph{flexibilit\'e}.  
La flexibilit\'e dans un overlay est d\'efinie par Gummadi \emph{et al.} \cite{gummadi03impact} comme le degr\'e de libert\'e qui subsiste une fois donn\'ee 
l'infrastructure de routage de base. Cette libert\'e peut s'exercer dans le choix (i) des voisins, (ii) des routes. 
\begin{description}
 \item[]S\'election du voisinage : Dans certaines solutions le choix des voisins est totalement d\'eterministe
(\'etant donn\'e un ensemble d'identifiants de n\oe uds, les tables de routage sont compl\`etement d\'etermin\'ees). Dans d'autres, un degr\'e de libert\'e 
existe dans le choix des voisins, ce qui permet de prendre en compte une vari\'et\'e de crit\`eres, comme par exemple l'h\'et\'erog\'eit\'e des n\oe uds en termes de ressources ou la 
promixit\'e r\'eseau pour une meilleure latence. 
\item[]S\'election des routes : \'Etant donn\'es un ensemble de voisins et une requ\^ete, le protocole de routage d\'etermine le(s) prochain(s) saut(s), c'est-\`a-dire le(s) prochain(s) n\oe ud(s) auquel transmettre la requ\^ete. Cette libert\'e est importante pour deux raisons. La premi\`ere raison tient \`a la robustesse du syst\`eme. 
Lorsque l'algorithme de routage s\'electionne un voisin qui est en panne, 
la flexibilit\'e d\'ecrit le nombres d'alternatives dont dispose un n\oe ud. Si le nombre est r\'eduit voire nul, 
alors l'algorithme de routage se montre peu r\'esilient. 
La seconde raison tient \`a l'optimisation des routes. Un degr\'e de libert\'e dans le choix de la route permet de s\'electionner 
sur des crit\`eres, comme la proximit\'e (ou localit\'e) g\'eographique.
 \end{description}

% entre autres, le degr\'e de libert\'e 
% %dont dispose un n\oe ud dans le choix du n\oe ud suivant auquel transmettre une requ\^ete donn\'ee.
% dont dispose un n\oe ud dans le choix du n\oe ud auquel transmettre une requ\^ete.  

% \paragraph {\textbf{~~~Crit\`ere 4 (Flexibilit\'e dans le choix des routes)}} \textit{Dans un \'etat donn\'e et pour une destination donn\'ee, le syst\`eme 
% a le choix entre plusieurs routes.}
Ainsi, d'apr\`es la taxonomie ci-dessus, les overlays structur\'es offrent le moins de flexibilit\'e, les overlays non-structur\'e le plus de flexibilit\'e et les 
overlays semi-structur\'es un niveau interm\'ediaire de flexibilit\'e. Toutefois il existe des variations de flexibilit\'e au sein m\^eme des classes, qui peuvent 
justifier le choix d'une g\'eom\'etrie plut\^ot qu'une autre. 
De plus, comme le montrent les exemples donn\'es ci-apr\`es, nombreuses sont les solutions hybrides, cherchant \`a combiner les avantages
des approches structur\'ees et non-structur\'ees. % : des g\'eom\'etries sont augment\'ees de liens, d'autres sont hi\'erarchis\'ees, \ldots.

\subsection{Etude des overlays P2P structur\'es et semi-structur\'es} \label{subsec:etudesoverlaysstructures}

La quantit\'e de solutions, l'influence de domaines ext\'erieures, l'existence de solutions hybrides, sont des conditions qui 
rendent difficile la classification des overlays P2P. 
De nombreuses taxonomies d'index distribu\'es et notamment d'overlay P2P sont propos\'ees dans la litt\'erature \cite{lua05survey, risson06survey, meshkova08survey}. 
Une classification classique consiste \`a distinguer deux cat\'egories : les overlays P2P bas\'es DHT et les autres.   
%Notre classification se distingue de ces \'etudes en essayant de d\'epasser la dichotomie classique DHT/non DHT. 
% Discriminant les solutions sur le seul crit\`ere 
% du hachage comme strat\'egie de placement, cette classification ne nous para\^it pas offrir un cadre conceptuel totalement satisfaisant.
Plut\^ot que de discriminer les solutions sur le seul crit\`ere du hachage comme strat\'egie de placement, notre \'etude tente de 
mettre en lumi\`ere l'articulation entre strat\'egie de routage, strat\'egie de placement et l'incidence sur les propri\'et\'es de l'overlay
du choix combin\'e des deux strat\'egies. 

Nous avons vu pr\'ec\'edemment les \'etapes g\'en\'eriques de conception d'un overlay P2P et notamment d'un overlay structur\'e ou 
semi-structur\'e. 
Si ces \'etapes sont communes \`a toutes les solutions d'overlay P2P, l'\'etude des solutions propos\'ees laisse appara\^itre que les auteurs adoptent 
en g\'en\'eral deux approches, qui sont en quelque sorte l'inverse l'une de l'autre : 
\begin{enumerate}
	\item \textbf{Approche dirig\'ee par le routage} : Une topologie logique des pairs est s\'electionn\'ee pour ses bonnes propri\'et\'es de routage. 
En fonction de quoi, une strat\'egie de placement des solutions est appliqu\'ee, de laquelle d\'ependra les types de requ\^ete support\'es par le syst\`eme ;
	\item \textbf{Approche dirig\'ee par les donn\'ees} : Une structure de donn\'ees est s\'electionn\'ee pour ses bonnes propri\'et\'es de recherche. 
En fonction de quoi, une strat\'egie de placement des solutions est \'elabor\'ee, de laquelle d\'ependra l'inter-connexion des n\oe uds. 
\end{enumerate}

% >> >> >> >> >> >> >> >>> inserer pt de vue http://ilpubs.stanford.edu:8090/581/1/2003-1.pdf avec 3 dim : autonomie, robustesse, efficacite ?
%au regard de l'importance accord\'ee dans nos travaux \`a l'expressivit\'e du mod\`ele de requ\^etes support\'e.  

L'\'etat de l'art qui suit est d\'ecoup\'e en deux parties, afin de rendre compte des deux approches. 
Pour chaque approche, nous distinguons les structures employ\'ees. 
Pour chaque solution, les usages sont pr\'ecis\'es (mod\`eles de donn\'ees et de requ\^etes support\'es), autorisant une 
comparaison des avantages et limitations de chacune. Nous esp\'erons ainsi fournir au lecteur une vue 
repr\'esentative, \`a d\'efaut de pouvoir \^etre exhaustive, des possibilit\'es offertes par le choix du paradigme P2P pour la conception d'index. 

Pour des raisons de concision, nous nous limitons aux mod\`eles de donn\'ees et de requ\^etes dans le spectre de nos travaux : 
requ\^etes exactes uni/multidimensionnelles, requ\^etes par plages de valeurs uni/multidimensionnelles, requ\^etes skyline, etc.

\section{Etat de l'art : Conception dirig\'ee par le routage d'overlays P2P structur\'es} \label{sec:Etatdelart : Conception dirig\'ee par le routage d'overlays P2P structur\'es}

Selon cette approche, le choix de la topologie logique des pairs d\'etermine l'index. L'accent est mis sur le choix du graphe d'inter-connexion des pairs qui 
optimise le routage des requ\^etes tout en minimisant l'\'etat des pairs \footnote{L'\emph{\'etat} d'un pair d\'esigne ici les m\'eta-donn\'ees maintenues par un pair, telle que 
la table de routage.}.
La figure \ref{fig:conceptionDirigeeRoutage} illustre les \'etapes g\'en\'eriques de conception d'un overlay P2P dirig\'ee par le routage.
En reprenant les notations introduite en \ref{conceptionGenerique} : \`A l'\'etape I, les n\oe uds de $f\langle \mathcal{N} \rangle$ sont organis\'es selon 
une topologie poss\'edant de bonnes propri\'et\'es de routage (\cite{gummadi03impact} emploie \'egalement le terme de \emph{g\'eom\'etrie}). 
\`A l'\'etape II, les donn\'ees de $g\langle \mathcal{O} \rangle$ sont plac\'ees sur les n\oe uds selon la fonction $p$. 

\begin{figure}[!h]
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.7\textwidth]{fig/conceptionDirigeeRoutage.png}
		\caption{TODO Rajouter en dessous n\oe uds/topologie/donn\'ees/placement des donn\'ees sur les n\oe uds\\\ Processus g\'en\'erique de conception d'un overlay en partant de la g\'eom\'etrie des n\oe uds}
	\label{fig:conceptionDirigeeRoutage}
\end{figure}

% Toutes les g\'eom\'etrie d'overlay partagent les points communs suivants : i) $N$ n\oe uds ??? identifiant ; ii) une fonction de distance
% entre les noms/cl\'es; iii) un algorithme de routage glouton 
% \footnote{On d\'efini un routage glouton de la mani\`ere suivante : Dans un graphe $(V,E)$ muni d'une fonction de distance 
% $\delta : V \times V \rightarrow \mathcal{\mathbb{R}}^+$
% , on parle de routage \emph{glouton} lorsqu'\'etant donn\'e un n\oe ud INSERER FORMULE}
% 
% %$\delta : V \times V \rightarrow \mathcal{\mathbb{R}}^+$, on parle de routage \textbf{glouton} lorsqu'\'etant donn\'e un n\oe ud INSERER FORMULE }
% %cible $c$, un n\oe ud $u$ dot\'e d'un voisinage $V(u)$ transmet une requ\^ete au voisin $v \in V(u) \text{ tel que } \delta (v,c)=\min_{x \in V(u)} \delta (x,c)$}
% %$v \in V (u) \text{ tel que } \delta (v, c)=\min_{x \in V (u)} \delta (x, c)$. }
% ,minimisant la distance s\'eparant le n\oe ud courant de la destination (entre
% $f$ et $u_i$.). L\`a o\`u les solutions diff\`erent, c'est dans la
% d\'efinition de la distance. Cette distance d\'epend du graphe/topologie
% logique/g\'eom\'etrie des pairs sous-jacent (ou pour employer les termes de
% Gummadi \emph{\emph{\emph{et al.}}}, la  g\'eom\'etrie de routage   ou \textit{routing geometry
% }[Gummadi   The Impact of DHT Routing Geometries on Resilience and Proximity 
% ]).


%\footnote{Naor \emph{\emph{\emph{et al.}}} proposent une optimisation du routage glouton (appel\'e \textit{ neighbor of neighbor
% greedy }) pour les index bas\'es DHT. Leur algorithme peut \^etre impl\'ement\'e comme une sur-couche au-dessus du routage glouton et permet
% d'atteindre une longueur des routes optimale (nombre de sauts en O(log $n$/
% log log $n$)) tout en pr\'eservant les bonnes propri\'et\'es du routage
% glouton (simplicit\'e, tol\'erance aux pannes et localit\'e dans l'espace de
% nommage). Ces travaux sont en-dehors de notre champ d'\'etude. Il est donc
% laiss\'e au lecteur int\'eress\'e le soin de se r\'ef\'erer \`a [  Know Thy
% Neighbor's Neighbor : Better Routing for Skip Graphs and Small Worlds  ]. }
%

Les g\'eom\'etries de pairs dans les index P2P structur\'es sont, pour la majorit\'e d'entre elles, adapt\'ees de mod\`eles de graphes d'interconnexion utilis\'es en architectures parall\`eles, 
largement \'etudi\'es depuis les ann\'ees 80 \cite{leighton94methods} : hypercubes, graphes de Bruijn, r\'eseaux papillon, etc.
Manku \cite{manku03routing} g\'en\'eralise l'approche en d\'emontrant que n'importe quelle topologie de routage parall\`ele 
peut \^etre r\'eutilis\'ee pour le routage dans un overlay P2P 
(nous nous contentons toutefois de pr\'esenter ici les topologies les plus commun\'ement rencontr\'ees).

% >> >> >> >> >> >> >> >> >>> parler des proprietes mathematiques, des garanties ? 
Ces topologies de graphes ont pour point commun de permettre un routage des
requ\^etes sur la base de tr\`es peu d'information (tr\`es faible degr\'e des
n\oe uds). Par exemple, nous montrons dans la suite qu'il suffit que les n\oe uds d'un graphe en anneau ait la connaissance d'un unique voisin, pour qu'une donn\'ee soit
localis\'ee et ce, quelque soit la taille du r\'eseau. Toutefois dans ce cas l'acc\`es est lin\'eaire et donc inefficace dans le cas g\'en\'eral. 
Une optimisation usuelle consiste \`a augmenter les informations de routage, ou en d'autres termes, \`a ajouter des liens dans le graphe. Le principe de
ces liens dits \emph{liens longs} est de cr\'eer des raccourcis entre n\oe uds distants dans le r\'eseau overlay. 
Le nombre de liens longs ajout\'es proc\`ede
d'un compromis entre deux objectifs contradictoires : minimiser l'\emph{\'etat} (taille des tables de routage) et minimiser la \emph{latence} 
(taille des routes).
Ainsi, pour prendre les cas limites du compromis, un routage en $1$ saut est optimal mais n\'ecessite un graphe complet des n\oe uds et
donc une taille des tables de routage maximale. A l'inverse, une taille des tables de routage minimale (\`a $1$ entr\'ee) 
induit en pire cas une recherche de complexit\'e lin\'eaire avec la taille de l'overlay.   
Si la taille des routes quantifie le co\^ut des recherches, 
la taille des tables de routage est li\'ee au co\^ut de la maintenance de l'overlay \cite{manku03symphony}. 
Un degr\'e faible par n\oe ud permet de r\'eduire le 
nombre de connexions TCP ouvertes simultan\'ement et le volume du trafic r\'eseau associ\'e (ping, keepalive, informations de contr\^ole). 
Un degr\'e faible permet aussi de limiter le nombre de n\oe uds \`a coordonner et verrouiller lors d'op\'erations de maintenance de 
l'overlay (mise-\`a-jour des \'etats voisins lors de l'arriv\'ee ou du retrait de n\oe uds).  

Typiquement, les r\'eseaux overlay structur\'es propos\'es dans la litt\'erature offrent un \emph{diam\`etre logarithmique}
 et des \emph{tables de routage compactes}, de taille constante ou bien logarithmique (Viceroy \cite{malkhi02viceroy} parvenant m\^eme \`a $O (1)$). 
Ces propri\'et\'es communes reposent sur une communaut\'e de choix de conception. 
Quelque soit la g\'eom\'etrie, (i) les n\oe uds sont repr\'esent\'es dans un \emph{espace m\'etrique}
(espace sur lequel est d\'efinie une distance), (ii) les n\oe uds sont parcourus selon un \emph{algorithme glouton} : une requ\^ete est achemin\'ee
de proche en proche et le choix du n\oe ud suivant sur la route minimisant une distance d\'efinie sur les n\oe uds. 
% Typiquement, les r\'eseaux overlay structur\'es offrent un diam\`etre
% logarithmique et des tables de routage compactes, de taille constante ou bien logarithmique (Viceroy \cite{malkhi02viceroy} parvenant m\^eme \`a $(O (1))$). 
L'utilisation
%d'espaces de nommage m\'etriques (ensemble sur lequel est d\'efinie une distance) et l'application sur un overlay de diam \`etre logarithmique 
d'un routage de type glouton dans un r\'eseau de diam\`etre logarithmique assure un routage en $O ( \text{ log } N)$ sauts dans le r\'eseau overlay (pour un r\'eseau de taille $N$ n\oe uds). 

% De mani\`ere g\'en\'erale, les diff\'erentes g\'eom\'etries, dont celles d\'etaill\'ees ci-dessous, se valent au regard du compromis \'etat/efficacit\'e.
% C'est ainsi que Gummadi \emph{\emph{\emph{et al.}}} proposent dans leur \'etude \cite{gummadi03impact} de diff\'erentier les g\'eom\'etries de routage 
% non plus sur les crit\`eres d'\'etat ou d'efficacit\'e, mais sur celui de la \emph{flexibilit\'e}. 
% Les auteurs caract\'erisent la flexibilit\'e d'une g\'eom\'etrie comme le degr\'e de libert\'e dont dispose un n\oe ud 
% dans le choix i) de ses voisins, ii) des routes. Lors de la constitution et de la maintenance des tables de routage, la g\'eom\'etrie permet-elle
% \`a un n\oe ud de choisir ses voisins (par exemple en fonction de la proximit\'e) ou bien le choix est-il d\'eterministe ? Pour une table et une destination donn\'ees,
% la g\'eom\'etrie permet-elle \`a un n\oe ud de  choisir le prochain saut ? 

% Quelque soit la g\'eom\'etrie \'evoqu\'ee, 
% elle est en g\'en\'eral parcourue selon un algorithme glouton : le routage se fait de saut en saut en 
% diminuant \`a chaque saut la distance au n\oe ud cible (et puisque le diam\`etre du graphe est logarithmique, le routage ).

Pour une m\^eme g\'eom\'etrie, diff\'erentes strat\'egies de placement peuvent \^etre appliqu\'ees. Le choix de la strat\'egie impacte 
les propri\'et\'es fonctionnelles et non-fonctionnelles du syst\`eme.
Les strat\'egies se distinguent essentiellement sur un point : la pr\'eservation -ou non- de la \emph{localit\'e}. 
En effet, les requ\^etes par intervalles de valeurs ou de comparaison ont pour objet la recherche de donn\'ees corr\'el\'ees, ou proches s\'emantiquement. 
Leur ex\'ecution est donc rendue plus efficace lorsque la localit\'e s\'emantique de ces donn\'ees est pr\'eserv\'ee par la proc\'edure d'indexation. Intuitivement, 
deux donn\'ees consid\'er\'ees comme proches (en termes de s\'emantique)
sont alors stock\'ees par l'index dans un voisinage proche (en termes de distance de communication). Autrement dit, 
lorsque la localit\'e s\'emantique des donn\'ees est pr\'eserv\'ee, la recherche dans l'index de donn\'ees proches s\'emantiquement se ram\`eme alors \`a une
recherche dans un espace. L'\'etude de l'existant en \ref{sec:Etat de l'art : Conception dirig\'ee par les donn\'ees d'overlays P2P structur\'es} et en \ref{sec:Etat de l'art : Conception dirig\'ee par les donn\'ees d'overlays P2P structur\'es} s'attache donc plus particuli\`erement aux solutions d'index pr\'eservant la localit\'e des donn\'ees dans l'espace d'origine.
 
% ainsi qu'\`a 
% l'\'etude de la corr\'elation entre les caract\'eristiques d'un ordre et les fonctionnalit\'es de recherches qui en d\'ecoulent. 

% : quel mod\`ele de donn\'ees et de requ\^etes sont support\'es ? propri\'et\'es de r\'epartition de la charge ? 


% Par exemple, un hachage pr\'ealable des donn\'ees permet un placement simple, r\'eparti la charge en termes de nombre de donn\'ees
% par n\oe ud et offre un support efficace aux requ\^etes exactes. N\'eanmoins le hachage est peu compatible avec le traitement des requ\^etes de comparaison ou par intervalles.  
% N\'eanmoins, cette sous-section montre pourquoi le hachage est 
% peu compatible avec des recherches plus complexes, telles que les requ\^etes de comparaison ou par intervalles. 

%Une fois  la g\'eom\'etrie et de l'algorithme de routage fournit une plateforme de routage compl\`ete. Une fois la g\'eom\'etrie fix\'ee, 
% il ne reste plus donc qu'\`a d\'eterminer une mani\`ere de placer les solutions sur les pairs pour obtenir un mod\`ele d'overlay op\'erationnel. 

Dans ce qui suit, nous \'evoquons les g\'eom\'etries couramment rencontr\'ees dans la litt\'erature. Sur deux exemples types (l'anneau et le tore), nous pr\'esentons un \'eventail de strat\'egies de 
placement couramment rencontr\'ees, les types de requ\^etes qu'elles supportent et des solutions qui les impl\'ementent. L'objectif poursuivi est de donner un aper\c cu 
des solutions orient\'ees routage et des possibilit\'es offertes par diff\'erentes associations de strat\'egies de routage et de strat\'egies 
de placement.  

% >> >> >>[TODO inserer schema /anneli/thesis/binder/StructuresGraphe.ppt]

% la longueur d'une route (ou distance de routage) est d\'efinie comme le nombre de
% liens travers\'es sur une route.

\subsection{G\'eom\'etrie en anneau} \label{anneau} 
Cette topologie fondatrice, propos\'ee par Sto\"ica \emph{et al.}\cite{stoica01chord, chord}, 
sert de substrat \`a de nombreuses solutions de la litt\'erature. 
Dans une topologie en anneau, les n\oe uds sont organis\'es en cha\^ine, le dernier n\oe ud de la cha\^ine \'etant reli\'e au premier. 
%Chaque n\oe ud re\c coit un identifiant qui est l'empreinte de sa cl\'e (mment son IP et son num\'ero de port) calcul\'ee par une fonction de hachage (typiquement SHA-1)
Chaque n\oe ud re\c coit un identifiant de $m$ bits qui est l'empreinte de sa cl\'e (typiquement son adresse IP),
 obtenue \`a l'aide d'une fonction de hachage (typiquement, SHA-1). 
% et la cardinalit\'e de l'espace des empreinte est \'egale \`a $2^{160}$. 
L'ordre des n\oe uds sur l'anneau suit l'ordre total sur les empreintes (modulo $2^m$, pour rendre l'ordre circulaire). 
Chaque n\oe ud d\'etient une r\'ef\'erence sur le n\oe ud qui le suit imm\'ediatement sur l'anneau, appel\'e son \emph{successeur}. 
%Dans cette configuration minimale, un n\oe ud ne re\c coit de requ\^etes que de son pr\'ed\'ecesseur sur l'anneau, et ne transmettant de requ\^etes qu'\`a son successeur sur l'anneau. 
Cette configuration est minimale et suffisante : il suffit pour chaque n\oe ud de conna\^itre son successeur pour que soit localisable toute donn\'ee index\'ee. 
Toutefois dans cette configuration, la recherche est s\'equentielle et la complexit\'e lin\'eaire en pire cas (communication unidirectionnelle)
\footnote{Certes l'esp\'erance est de $N/2$, mais il faut tenir compte du fait que chaque n\oe ud travers\'e implique une communication r\'eseau TCP/IP.}. 
Afin d'optimiser la propagation des requ\^etes, la topologie en anneau de base de Chord est augment\'ee de liens longs. 
%Ces liens, dits << longs >> car reliant des n\oe uds distants, fonctionnent comme autant de raccourcis. 
Chaque n\oe ud maintient d\'esormais non plus un pointeur unique mais une table de pointeurs, de taille maximale $m$ (appel\'ee <<\~ finger table >>). 
Le choix des pointeurs s'effectue suivant une distribution harmonique : soit $H( P )$ l'empreinte du n\oe ud $P$, pour tout $i=0,1,2, \ldots$, 
la $i$-\`eme entr\'ee de sa table contient le pointeur sur le n\oe ud qui suit imm\'ediatement $H( P )+2^{i-1}$ (modulo $2^m$ toujours).
%la $i$-\`eme entr\'ee de sa table pointe sur le n\oe ud d'identifiant le plus proche de $H( P )+2^i$. 
Chaque n\oe ud connait donc ses successeurs
 \`a distance de $2^m$, ce qui rend la recherche dichotomique et conf\`ere au r\'eseau en anneau un diam\`etre logarithmique (taille des routes en pire cas : $N/2$, taille moyenne : $O(log N)$). 

\begin{figure}[!h]
\centering
\includegraphics[width=0.4\textwidth]{./fig/chord.png}
% Skipnet-routing.png: 500x290 pixel, 72dpi, 17.64x10.23 cm, bb=0 0 500 290
\caption{fig: Un r\'eseau Chord de 8 n\oe uds, le placement de 4 donn\'ees et un exemple de << finger table >>}
\label{routage chord}
\end{figure}

Toujours sur le principe d'un routage en anneau de Chord, d'autres distributions des liens longs sont envisag\'ees. 
Ainsi Symphony \cite{manku03symphony} utilise une distribution en loi de puissance 
(type <<\~ petit monde >> \cite{newman03structure}), pour ses bonne propri\'et\'es de r\'eduction du diam\`etre r\'eseau. 

%tandis qu'Aurelia \cite{wu05aurelia} 

\subsubsection{Utilisation d'une fonction de hachage : Exemple de Chord} \label{subsubec:Utilisation d'une fonction de hachage : Exemple de Chord}
%Comme mentionn\'e plus t\^ot, l'utilisation d'une topologie en anneau pour organiser les n\oe uds d'un overlay P2P a \'et\'e propos\'ee pour la premi\`ere fois dans Chord \cite{stoica01chord}. 
%\subparagraph{Fonctionnement}
Historiquement, la strat\'egie de placement sur un anneau repose sur le hachage \`a la fois des donn\'ees et des n\oe uds, dans 
un m\^eme espace d'arriv\'ee. Nous avons vu ci-dessus que les n\oe uds d'un overlay structur\'e en anneau sont organis\'es selon l'ordre total de leurs empreintes.  
Dans une strat\'egie de placement des donn\'ees par hachage, la m\^eme fonction de hachage est utilis\'ee pour hacher les cl\'es des donn\'ees (le plus souvent une cha\^ine de
caract\`eres).  
Le placement se fait ensuite en fonction de la proximit\'e num\'erique entre empreintes. Une cl\'e $k$ est enregistr\'ee aupr\`es du n\oe ud dont la valeur de l'empreinte est 
imm\'ediatement sup\'erieure ou \'egale \`a l'empreinte $H(k)$ de $k$. 
Autement dit, chaque n\oe ud est responsable d'une partie de l'espace de hachage. 
De mani\`ere plus g\'en\'erale, on trouve sous l'expression \emph{consistent hashing}\footnote{Parfois traduit en fran\c cais par << hachage homog\`ene >>.} 
les strat\'egies de placement qui, ayant calcul\'e les empreintes de hachage 
des donn\'ees et des n\oe uds, d\'efinissent une fonction de distance entre deux empreintes (d\'ecorr\'el\'ee de la latence ou de la distance g\'eographique)
et assignent \`a un n\oe ud la supervision des donn\'ees dont les empreintes sont les plus << proches >> de la sienne, selon la-dite distance. 

La localisation d'une donn\'ee se fait \`a l'aide de sa cl\'e $k$. Le routage est de type glouton : la requ\^ete est propag\'ee de successeur en successeur, 
jusqu'\`a atteindre le n\oe ud responsable de $H(k)$. 
\`A chaque saut, $H(k)$ est compar\'ee \`a l'intervalle de valeurs g\'er\'e par le n\oe ud courant. Si $H(k)$ est en-dehors de cet intervalle (cas o\`u $H(k)$ est 
sup\'erieur \`a la borne sup\'erieure de l'intervalle), la requ\^ete est transmise au voisin du n\oe ud dont l'empreinte est la plus proche pr\'ec\`edant $H(k)$. 
%La figure \ref{placement hachage} montre sur l'exemple d'anneau pr\'ec\'edemment introduit le placement de donn\'ees en fonction de leur empreinte. 
%
%\begin{figure}[!h]
%\centering
%\includegraphics[width=0.4\textwidth]{./fig/chord.png}
%% Skipnet-routing.png: 500x290 pixel, 72dpi, 17.64x10.23 cm, bb=0 0 500 290
%\caption{fig: Un reseau Chord 6 bits de 8 n\oe uds et 4 cl\'es }
%\label{placement hachage}
%\end{figure}
%\subparagraph{Requ\^etes permises} 

En r\'esum\'e, le placement par hachage sur un overlay structu\'e impl\'emente une DHT (cf. description donn\'ee en \ref{dht}), et seules
les requ\^etes par cl\'e sont possibles. 

%\subparagraph{Avantages}
Les avantages du placement par hachage sont les suivants : 
\begin{itemize}
\item Simplicit\'e ;
\item Faible co\^ut de recherche : une requ\^ete n\'ecessite typiquement $O( log N )$ sauts au lieu de $O( N )$ pour un routage par inondation ;
\item Faible co\^ut de mise-\`a-jour des tables de routage : le hachage consistant (de l'anglais <<\~ consistent hashing >>) a pour propri\'et\'e de limiter, lors du d\'epart ou de l'arriv\'ee d'un n\oe ud $n$, la mise-\`a-jour des cl\'es 
\`a celles d\'etenues par les voisins imm\'ediats de $n$ ;
\item R\'epartition uniforme des donn\'ees : la r\'epartition des empreintes sur chaque n\oe ud h\'erite des propri\'et\'es d'uniformit\'e de la fonction de hachage ;
\item Passage \`a l'\'echelle : Le nombre de pairs a une influence marginale sur les performances du routage des requ\^etes (la multiplication par deux du nombre de pairs n'induit qu'un saut de plus sur la route). 
\end{itemize}

Les limitations sont les suivantes : 
%\subparagraph{Limitations}
\begin{itemize}
\item Perte de la localit\'e s\'emantique : le hachage d\'etruit l'ordre sur les cl\'es (deux cl\'es semblables peuvent avoir des empreintes tr\`es diff\'erentes). En 
cons\'equence, il est tr\`es co\^uteux \`a partir d'une DHT de r\'epondre \`a des requ\^etes de similiarit\'e ou portant sur un intervalle ;
\item Mod\`ele de donn\'ees unidimensionnel : le hachage est une projection de l'espace des donn\'ees, potentiellement multidimensionnel, sur un espace unidimensionnel (l'espace des empreintes) ;
\item Faible expressivit\'e des requ\^etes support\'ees : d\'ecoule directement du mod\`ele de donn\'ees support\'e (cl\'e-valeur). Le placement par hachage n'est 
adapt\'e qu'aux requ\^etes exactes. Par ailleurs, il n\'ecessite une connaissance compl\`ete \emph{a priori} de la cl\'e. 
\end{itemize}
%\vspace{1cm}
%Bonnel propose des ex. d utilisation de Chord.

%Les strat\'egies de placement suivantes ont souvent pour objectif le d\'epassement de ces limitations du placement par hachage.  

\vspace{0.6cm}

Une mani\`ere de contourner les limitations li\'ees au hachage des donn\'ees est de hacher des \emph{r\'egions} de donn\'ees.  
Ainsi Tanin \emph{et al.} dans \cite{tanin07using} proposent-ils de diviser l'espace des donn\'ees en hyper-rectangles 
%par le biais d'un arbre quaternaire (sorte d'arbre kd dont les n\oe uds interm\'ediaires poss\`dent exactement quatre fils). 
Chaque hyper-rectangle est assimil\'e \`a un point (son centre g\'eom\'etrique), nomm\'e point de contr\^ole. 
Ce sont les coordonn\'ees de ces points de contr\^ole qui sont hache\'ees et leurs empreintes plac\'ees sur les n\oe uds de l'overlay connect\'es en anneau. Une illustration du processus est donn\'ee en figure \ref{fig:quadtree}.
% Tanin \emph{\emph{\emph{et al.}}} dans \cite{tanin07using} proposent de distribuer un arbre quaternaire (sorte d'arbre kd dont les n\oe uds interm\'ediaires poss\`dent exactement quatre fils) %de type MX-CIF \cite{kedem82quad-cif}) 
% \`a l'aide d'un overlay P2P structur\'e en anneau. 
% Partant de la partition en hyper-rectangles de l'espace des solutions du quadtree, les auteurs identifient 
% chaque hyper-rectangle \`a son centre g`'eom\'etrique, d\'esign\'e comme son "point de contr\^ole". Les coordonn\'ees des 
% points de contr\^ole sont hache\'ees et les cl\'es ainsi obtenues plac\'ees sur les n\oe uds, connect\'es en anneau. 
Cette solution supporte les requ\^etes par intervalles. Sur r\'eception d'une telle requ\^ete, un n\oe ud
calcule les points de contr\^ole couverts par la r\'egion recherche\'ee et diffuse
la requ\^ete aux n\oe uds responsables des dits points. \`A l'it\'eration suivante, un n\oe ud recevant une requ\^ete et le point de contr\^ole
calcul\'e \`a l'\'etape pr\'ec\'edente calcule l'intersection entre l'intervalle de la requ\^ete et le rectangle identifi\'e par 
le point de contr\^ole. Le routage se poursuit r\'ecursivement avec la transmission de la requ\^ete aux enfants du n\oe ud courant. 
\begin{figure}[!h]
\centering
\includegraphics[width=0.8\textwidth]{./fig/quadtree_ang.png}
% Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
%\caption{TODO \`a traduire Exemple de projection d'un quadtree sur un anneau}
\caption{TODO traduire /// Division d'un espace des donn\'ees en 2 dimensions et placement des r\'egions sur un overlay structur\'e en anneau}
\label{fig:quadtree}
\end{figure}
% Les limitations que nous entrevoyons \`a cette proposition sont li\'ees d'une part \`a la nature m\^eme de la structure de donn\'ees choisie
% , et d'autre part \`a l'approche bas\'ee DHT. Pour commencer donc, les distributions de donn\'ees dynamiques sont mal g\'er\'ees par le
% quadtree, en tant que technique de partition de l'espace des solutions \cite{worboys04gis}. Chaque modification de la distribution peut 
% en effet entra\^iner une r\'eorganisation massive de la structure de l'arbre. Cette limitation contrevient \`a l'hypoth\`ese d'un environnement dynamique qui est la notre. 
Toutefois, cette approche ne conserve que partiellement la localit\'e des donn\'ees : si le m\^eme pair peut superviser 
des donn\'ees proches dans l'espace d'origine, une r\'egion faisant l'objet de recherche peut correspondre \`a des points de contr\^ole compl\`etement 
dispers\'es sur l'anneau (cf. aussi le cas de Squid, cf. partie \ref{subsubsec:Utilisation d'une courbe de remplissage : exemple de Squid}). 
L'efficacit\'e de la recherche est donc fortement tributaire de la
distribution des donn\'ees et de la nature de la requ\^ete (intervalle plus ou moins large, \ldots). 
Pour finir ce paragraphe, mentionnons parmi les travaux relevant de la m\^eme approche l'adaptation d'un arbre (B+) au-dessus de Chord par 
P-Tree \cite{crainiceanu04querying}, dont une description critique peut \^etre trouv\'ee dans \cite{jagadish05baton}.  
% pas mention de adaptatation trie par Ratnasamy et Francis car trouve que rapports techniques


\subsubsection{Utilisation d'une fonction de hachage pr\'eservant la localit\'e : Exemple de MAAN} \label{subsubsec:Utilisation d'une fonction de hachage pr\'eservant la localit\'e : Exemple de MAAN} 
MAAN \cite{cai04maan} r\'e-utilise la strat\'egie de routage de Chord (cf. \ref{subsubec:Utilisation d'une fonction de hachage : Exemple de Chord}), 
en lui substituant dans la strat\'egie de placement une 
fonction de hachage pr\'eservant la localit\'e (\emph{Locality Preserving Hashing} ou LPH) \`a la fonction de hachage standard (typiquement SHA-1). 
Seuls sont hach\'es les attributs num\'eriques (les identifiants des n\oe uds et des attributs 
de type cha\^ines de caract\`eres ne sont pas concern\'es). 
Si les applications divergent selon l'acceptation du terme << localit\'e >>, les auteurs de MAAN en donnent la d\'efinition suivante \cite{cai04maan} : 
La fonction de hachage $h$ est une fonction de hachage pr\'eservant la localit\'e si elle v\'erifie les deux propri\'et\'es suivantes : (i) $h(v_i)<h(v_j)$ ssi $v_i<v_j$ et (ii) si un intervalle $[v_i,v_j]$ est d\'ecoup\'e en $[v_i,v_k]$ et $[v_k,v_j]$, 
alors l'intervalle correspondant $[h(v_i),h(v_j)]$ doit \^etre partag\'e en $[h(v_i),h(v_k)]$ et $[h(v_k),h(v_j)]$. 
Par ailleurs les auteurs s'attachent \`a \'elaborer des LPH uniformes. 
L'avantage retir\'e est de permettre l'\'elaboration d'une strat\'egie de placement de 
donn\'ees unidimensionnelles
%\footnote{Il n'est pas clair pour la r\'edactrice pourquoi les auteurs de MAAN n'utilisent pas une g\'en\'eralisation des LPH \`a des dimensions plus \'elev\'ees \cite{indyk97locality-preserving}\ldots} 
alliant \`a la fois les 
b\'en\'efices d'une fonction de hachage uniforme (r\'epartition de la charge en termes de stockage entre les n\oe uds) et les b\'en\'efices de la localit\'e, ce
qui lui permet d'optimiser le traitement des requ\^etes par intervalles. 
Soit $h$ une LPH uniforme, le principe de la localisation dans l'overlay MAAN est le suivant.    
Pour une requ\^ete portant sur l'intervalle $[l,u]$, MAAN \cite{cai04maan} r\'e-utilise l'algorithme de routage de Chord pour acheminer 
la-dite requ\^ete jusqu'au n\oe ud $n_l$ successeur de $h(l)$. 
$n_l$ retourne les solutions intersectant son domaine et celui de la requ\^ete, puis v\'erifie s'il est aussi le successeur de $h(u)$. 
Si tel est le cas, le processus de recherche prend fin. Sinon la requ\^ete est transmise au successeur imm\'ediat $n_i$ de $n_l$ pour une nouvelle
it\'eration de l'algorihme, jusqu'\`a ce que le n\oe ud $n_u$ successeur de $h(u)$ soit atteint. Le principe de la recherche 
est \'etendu aux requ\^etes $d$-dimensionnelles en g\'en\'erant une LPH pour chaque attribut et en superposant les DHT : 
d\'esormais, chaque n\oe ud supervise $d$ intervalles et maintient la connaissance de $d$ successeurs. %Les requ\^etes multidimensionnelles sont r\'esolues localement \`a un n\oe ud par d\'ecomposition en requ\^etes unidimensionnelles et intersection des solutions.  
Enfin, MAAN supporte les requ\^etes multidimensionnelles en ramenant leur r\'esolution \`a 
la r\'esolution de requ\^etes unidimensionnelles. Le principe de ce type d'approche (cf. Mercury en \ref{subsubsec:Partition de solutions et utilisation de plusieurs overlay : Exemple de Mercury}) 
est de d\'ecomposer les requ\^etes en sous-requ\^etes
unidimensionnelles et de maintenir une DHT s\'epar\'ee pour chaque dimension, d\'edi\'ee \`a la r\'esolution des sous-requ\^etes portant sur l'attribut 
correspondant. Les limitations de cette approche sont de n\'ecessiter la connaissance \emph{a priori} de la distribution des donn\'ees requises, et la difficult\'e de passer 
\`a l'\'echelle en termes de dimensionnalit\'e \'etant donn\'e le recours \`a une DHT par dimension. 
%Nous renvoyons le lecteur int\'eress\'e par MAAN et l'approche par LPH aux travaux de Gupta, Agrawal \emph{\emph{\emph{et al.}}}} \cite{gupta03approximate}. 

Une approche comparable pour le support de requ\^etes par intervalles a \'et\'e \'elabor\'ee par Gupta, Agrawal \emph{et al.} \cite{gupta03approximate}. Cette approche permet de g\'erer des requ\^etes de type SQL
(requ\^etes de jointure). Partant des relations d'une base de donn\'ees, les auteurs 
distribuent sur un m\^eme n\oe ud d'un overlay structur\'e en anneau des intervalles \emph{similaires} de valeurs d'attributs qu'ils hachent \`a l'aide d'une LPH 
 (en d'autres termes, compar\'e \`a MAAN sont hach\'es non plus des valeurs discr\^etes mais des intervalles de valeurs). 
Toutefois cette approche ne permet que de fournir des solutions approximatives. 

\subsubsection{Utilisation d'une courbe de remplissage : exemple de Squid} \label{subsubsec:Utilisation d'une courbe de remplissage : exemple de Squid}
% \begin{floatingfigure}[option]{8cm}
% 	\centering
% 	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
% 		\includegraphics[width=0.4\textwidth]{fig/squid1}
% 		\caption{R\'egions de l'espace des solutions correspondant aux requ\^etes par intervalles : $(000,*)$ et $(1*,0*)$}
% \label{fig:squid}
% \end{floatingfigure}
Partant d'un espace de solutions multidimensionnel, l'approche adopt\'ee par Squid \cite{andrzejak02scalable} est de lui faire 
subir une r\'eduction de la dimensionnalit\'e afin de se ramener au cas du routage
dans un espace de cl\'es unidimensionnel : l'espace est lin\'earis\'e (en d'autres termes sa dimension r\'eduite \`a $1$) gr\^ace \`a une \emph{courbe remplissante} \cite{morton66computer}
(aussi appel\'ee courbe de couverture ou de recouvrement de l'espace, ou encore SFC de l'anglais << space-filling curves >>).
Une courbe remplissante de dimension $n$ est une application continue surjective de $[0,1]$ sur $[0,1]^n$. \begin{floatingfigure}[option]{8cm}
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.4\textwidth]{fig/squid1}
		\caption{R\'egions de l'espace des solutions correspondant aux requ\^etes par intervalles : $(000,*)$ et $(1*,0*)$}
\label{fig:squid}
\end{floatingfigure}
En particulier, une courbe remplissante de dimension 2 est une courbe continue traversant chaque point d'un carr\'e unit\'e $[0,1]^2$. Apr\`es application de la fonction, 
un point dans l'espace d'origine peut \^etre identifi\'e sur la courbe obtenue par la distance s\'eparant ce point et l'une des extr\'emit\'es de la courbe. 
Les SFC pr\'eservent la localit\'e des donn\'ees : deux images proches sur la courbe ont forc\'ement des ant\'ec\'ecents proches 
dans l'espace d'origine (en revanche, deux points proches dans l'espace d'origine n'ont pas forc\'ement des images proches sur la courbe). 
Les SFC offrent donc le double avantage par rapport aux fonctions de hachage traditionnelles
d'une gestion native des attributs multidimensionnels, \'evitant l'empilement de DHT d\'ecrit plus haut dans MAAN, et d'une
partition des donn\'ees pr\'eservant la localit\'e. Des exemples de SFC rencontr\'ees dans les travaux r\'ef\'erenc\'es ici sont la courbe de Hilbert \cite{hilbert1891uber} 
et la courbe Z\cite{morton66computer}. 

La strat\'egie de routage choisie est d'attribuer des cl\'es g\'er\'ees al\'eatoirement aux n\oe uds et de les connecter en une topologie de routage 
en anneau, \`a la Chord. La strat\'egie de partition comporte alors deux \'etapes : 
(i) construction de la courbe de Hilbert associ\'ee \`a l'espace des donn\'ees d'origine (hypercube) ; 
(ii) segmentation de la courbe obtenue et affectation d'un segment \`a chaque n\oe ud (un segment correspondant \`a un intervalle de valeurs cons\'ecutives dans le nouvel espace 
de solutions unidimensionnel).  
La r\'esolution d'une requ\^ete par intervalles multidimensionnelle se fait \'egalement en deux temps : (i) identification des segments cons\'ecutifs 
(nomm\'es << clusters >>) parcourant la r\'egion de l'espace des solutions d\'elimit\'ee par la requ\^ete (cf. figure \ref{fig:squid}), 
(ii) envoi de la requ\^ete aux n\oe uds responsables de ces clusters.   
% \begin{figure}[!h]
% \centering
% \includegraphics[width=0.4\textwidth]{./fig/squid1.png}
% % Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
% \caption{R\'egions de l'espace des solutions correspondant aux requ\^etes par intervalles : $(000,*)$ et $(1*,0*)$}
% \label{fig:squid requete}
% \end{figure}
A noter que Squid h\'erite des limitations de Chord, notamment une sensibilit\'e des performances de routage \`a la distribution des donn\'ees.  
L'utilisation de SFC pr\'esente l'inconv\'enient que des donn\'ees contigu\"es dans l'espace d'origine peuvent se retrouver \'eclat\'ees 
sur des segments non-cons\'ecutifs de la courbe, qui n\'ecessitent d'\^etre recherch\'es s\'epar\'ement. 

\subsubsection{Partition de solutions et utilisation de plusieurs overlay : Exemple de Mercury} \label{subsubsec:Partition de solutions et utilisation de plusieurs overlay : Exemple de Mercury}
%L'ensemble solution de la requ\^ete multidimensionnelle est ensuite calcul\'e au niveau du n\oe ud d'entr\'ee en effectuant l'intersection des r\'esultats des sous-requ\^etes retourn\'es par chaque DHT. Le routage des sous-requ\^etes
%Le routage de la requ\^ete est effectu\'e dans la DHT de l'attribut le plus discriminant, afin de minimiser le nombre de pairs \`a contacter et donc les co\^uts de communication aff\'erents. 
Dans le m\^eme esprit que MAAN, Mercury \cite{bharambe04mercury} maintient non pas une mais plusieurs DHT, d\'enomm\'ees \emph{attribute hub}, 
une par dimension orthogonale de l'espace des solutions. La strat\'egie de placement des solutions sur ces << hub >>
est simple : le domaine de d\'efinition de l'attribut concern\'e est d\'ecoup\'e en intervalles de valeurs cons\'ecutives et chaque intervalle est affect\'e \`a un n\oe ud
du << hub >>. Un n\oe ud du << hub >> $H_a$ associ\'e \`a l'attribut $a$, fait correspondre \`a une valeur $v$ 
les donn\'es index\'ees v\'erifiant le pr\'edicat $(a=v)$. Les donn\'ees sont r\'epliqu\'ees sur tous les 
<< hub >>. M\^eme si Mercury ne recourt pas au hachage, la similarit\'e avec une DHT est grande : g\'eom\'etrie des n\o euds en anneau, 
utilisation de liens longs pour optimiser le routage au sein des \emph{hubs}, etc. 
N'utilisant pas de fonction de hachage, la propri\'et\'e de distribution uniforme des donn\'ees sur les n\oe uds n'est plus v\'erifi\'ee. Les auteurs en profitent
pour introduire un m\'ecanisme de r\'epartition de charge entre les n\oe uds : la taille relative de l'intervalle de valeurs attribu\'e \`a chaque n\oe ud est calcul\'ee en fonction de la popularit\'e de ces valeurs. Plus un n\oe ud re\c coit de requ\^etes et moins \'elev\'e est le nombre de valeurs qu'il lui est donn\'e \`a superviser.    
La strat\'egie de routage d'un << hub >> est celle d'une structure en anneau. Une requ\^ete multidimensionnelle est repr\'esent\'ee par une conjonction de pr\'edicats. 
Mercury s\'electionne un attribut $y$ parmi ceux
sur lesquels porte la requ\^ete et passe la requ\^ete au << hub >> $H_y$, ce qui permet de d\'eterminer l'ensemble des n\oe uds $E$ h\'ebergeant des 
donn\'ees candidates, c'est-\`a-dire satisfaisant au moins les conditions sur $y$. La requ\^ete est transmise \`a chaque n\oe ud appartenant \`a $E$.
L'ensemble des solutions satisfaisant la requ\^ete est constitu\'e de l'ensemble des donn\'ees retourn\'ees par les n\oe uds de $E$. 
Une optimisation du routage est propos\'ee, qui est de choisir le << hub >> correspondant \`a l'attribut le plus discriminant, 
ce qui permet de minimiser le nombre de pairs contact\'es et donc les co\^uts de communication aff\'erents. %, les auteurs soulignent que ce m\`ecanisme ne passe pas \`a l'\'echelle en termes de nombre dimensionnalit\'e. 
Toutefois cette strat\'egie suppose une connaissance \emph{a priori} de la distribution des donn\'ees, pas toujours disponible et violant notre crit\`ere 1.

%\subsubsection{Utilisation d'un arbre quaternaire : Exemple de \cite{tanin07using} / TODO}

\subsection{G\'eom\'etrie en tore $d$-dimensionnel} \label{subsec:G\'eom\'etrie en tore $d$-dimensionnel}

\begin{floatingfigure}[option]{7cm}
\includegraphics[width=0.2\textwidth]{./fig/tore.png}
% Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
\caption{Tore de dimension 2. 
%Un tore est engendr\'e par la rotation d'un cercle autour d'un autre cercle (adapt\'e de Wikipedia).
}
\label{fig:tore}
\end{floatingfigure}

L'utilisation d'un tore (figure \ref{fig:tore}) a \'et\'e propos\'ee par CAN (pour Content Addressable Network \cite{ratnasamy01scalable}).  
Par rapport au routage sur un anneau \`a la Chord, l'organisation des n\oe uds non plus selon un cercle
mais selon un tore de dimension $d$, permet d'optimiser le routage en autorisant les requ\^etes \`a emprunter $2^d$ directions pour atteindre leur destination. 

L'espace de nommage est l'espace Cart\'esien de dimension $d$, partitionn\'e en
hyper-rectangles. Chaque hyper-rectangle, appel\'e \emph{zone} dans CAN, est
affect\'e \`a un n\oe ud. % (on identifie un n\oe ud \`a sa zone). 
Deux n\oe uds sont voisins s'ils sont responsables de zones dont les coordonn\'ees se recouvrent sur exactement $d-1$ dimensions. 
La distance entre deux n\oe uds est \'egale \`a la distance euclidienne entre leurs coordonn\'ees.
Intuitivement, le routage dans un tore approxime donc la ligne droite dans l'espace cart\'esien entre les coordonn\'ees des n\oe uds source et destination. 
La taille moyenne des routes est de $(d/4)(N^{1/d})$. La figure \ref{fig:can} illustre un espace de coordonnn\'ees de dimension 2
%, $[0,1]\times[0,1]$
, r\'epartis entre 5 n\oe uds (pour des raisons de simplicit\'e, l'illustration montre le tore << d\'eroul\'e >>). 


\subsubsection{Utilisation d'une fontion de hachage : Exemple de CAN}
Dans la solution d'overlay structur\'e en tore originel de CAN, 
l'espace de nommage (cart\'esien) est d\'ecoup\'e en zones de tailles \'egales. 
Le placement d'une paire (cl\'e,valeur) s'effectue en calculant une empreinte de la cl\'e \`a l'aide d'une
fonction de hachage uniforme et en faisant correspondre \`a cette empreinte un 
point $p$ de l'espace des coordonn\'ees cart\'esiennes. Le pair responsable de la zone contenant $p$ est alors en charge  
du stockage de la paire (cl\'e, valeur) associ\'ee. 

% Pour faciliter la comparaison avec les autres solutions, on
% prend ici $d =$log $n$ et on raisonne sur un tore de dimension log $n$.
% La distance entre deux n\oe uds est \'egale \`a la distance euclidienne entre
% leurs coordonn\'ees. Chaque n\oe ud maintient une table de routage compos\'ee
% des n\oe uds partageant un plan de $d - 1$ dimensions (=> 2*log $n$ voisins).
% Lorsqu'il re\c coit une requ\^ete, un n\oe ud la transmet au n\oe ud parmi ses
% voisins le plus proche du n\oe ud cible, dans l'espace des coordonn\'ees. 
% La
% route emprunt\'ee par une requ\^ete lors du processus de recherche approxime
% par cons\'equent la ligne droite entre le n\oe ud d'entr\'ee de la requ\^ete et
% le n\oe ud cible, dans l'espace des coordonn\'ees.
% >> >> >> >>>[Pour des ex. d'applications construites par-dessus ces overlays, cf. Related Work dans {\cite{Tapestry}}


\begin{floatingfigure}[option]{8cm}
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.4\textwidth]{fig/can}
		\caption{Exemple d'overlay CAN en deux dimensions avec 5 n\oe uds. Le n\oe ud D a pour voisins C, B et E}
\label{fig:can}
\end{floatingfigure}

D\^u \`a la strat\'egie de placement par hachage, CAN fournit les fonctionnalit\'es d'une DHT. La d\'ecorr\'elation entre dimensionnalit\'e
de l'espace de nommage et dimensionnalit\'e du tore permet \`a CAN de fixer arbitrairement la valeur de $d$. La valeur choisie 
va d\'ependre du compromis d\'esir\'e entre performances de la maintenance 
de la structure et performances du routage : 
% Dans CAN, $d$ est fix\'e arbitrairement (et notamment
% $d$<log $n$). Le choix de $d$ d\'epend du compromis d\'esir\'e : 
une valeur \'elev\'ee de $d$ minimise la taille
des routes et donc favorise la vitesse de routage. A contrario, une faible dimensionnalit\'e minimise la 
taille des tables de routage et donc le co\^ut de maintien de l'overlay. 

\subsubsection{Utilisation d'un espace des attributs et partition dynamique de cet espace : exemple de SONAR}
Une extension directe de CAN permettant le support de donn\'ees multidimensionnelles et de requ\^etes par 
intervalles de valeurs est SONAR \cite{schutt07structured}. 
SONAR substitue \`a l'espace de nommage de CAN, form\'e de l'ensemble d'arriv\'ee de la fonction de hachage, 
un espace des attributs (tel que d\'efini en \ref{sec:Mod\`ele de donn\'ees utilis\'e}). 
Puis au lieu de fixer arbitrairement le nombre de dimensions du tore, 
SONAR choisit la valeur $d$ \'egale \`a la dimensionnalit\'e de l'espace des attributs : \`a chaque dimension du tore correspond une dimension
de l'espace des attributs. 
%SONAR substitue au hachage un espace des attributs tel que d\'efini en \ref{modele_donnees}. 
Il y a donc une correspondance directe entre l'espace de nommage et le plan du tore. 
Le d\'ecoupage en zones est effectu\'e dynamiquement, de telle mani\`ere \`a assurer \`a tout moment
 une r\'epartition de la charge entre n\oe uds (contrairement \`a CAN, les zones peuvent donc \^etre de tailles in\'egales). 

% \begin{figure}[!h]
% \centering
% \includegraphics[width=0.4\textwidth]{./fig/sonar.png}
% % Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
% \caption{Example d'overlay Sonar en deux dimensions avec 5 n\oe uds (pour des raisons de simplicit\'e, l'illustration montre le tore << d\'eroul\'e >>)}
% \label{fig:can}
% \end{figure}


\begin{floatingfigure}[option]{8cm}
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.2\textwidth]{fig/psearch}
		\caption{Instance de pSearch avec un CAN de dimension 2 << d\'epli\'e >>.}
\label{fig:psearch}
\end{floatingfigure}

Un autre exemple est pSearch \cite{tang03psearch}. 
pSearch traite de requ\^etes textuelles bas\'ee sur la s\'emantique, lesquelles sont en-dehors de notre champ d'investigation. 
Mais cette proposition d'overlay trouve sa place sans cette \'etude par son utilisation in\'edite d'un overlay de type DHT bas\'e sur CAN pour indexer des repr\'esentations 
vectorielles de documents. La strat\'egie de placement mise-en-\oe uvre permet \`a pSearch de conserver une localit\'e s\'emantique dans 
l'overlay et ainsi de supporter efficacement des requ\^etes complexes de comparaison (recherche de documents similaire \`a un document $p$ en contraignant le p\'erim\`etre
de recherche). 
Les repr\'esentations vectorielles sont g\'en\'er\'ees par des algorithmes emprunt\'es au domaine de la Rercherche d'Information. 
%L'algorithme de LSI (<< Latent Semantic Indexing >>) associe ainsi \`a chaque document un vecteur. 
L'algorithme de LSI (<< Latent Semantic Indexing >>) associe ainsi \`a chaque document un \emph{vecteur de termes}. 
Chaque dimension du vecteur correspond \`a une unit\'e s\'emantique ou \emph{terme} distinct (mot, groupe de mot, etc.). 
La valeur associ\'ee \`a un terme quantifie son importance ou poids dans le texte (en prenant en compte sa fr\'equence d'occurrence dans le texte 
et son caract\`ere discriminant par rapport \`a d'autres textes, par exemple). 
Une fois le document transform\'e en vecteur, son placement dans pSearch s'op\`ere de mani\`ere comparable \`a SONAR : 
les dimensions de l'espace des n\oe uds et de l'espace des donn\'ees sont choisies identiques, ce qui 
ram\`ene le placement d'un vecteur au placement d'un point $p$ dans un espace cart\'esien et \`a la recherche du n\oe ud supervisant la zone contenant $p$. 
Or dans l'espace des vecteurs de termes, la similarit\'e entre deux documents s'\'evalue selon le cosinus de l'angle entre
leurs vecteurs de termes respectifs. D\`es lors, le traitement d'une recherche des documents similaires \`a un document $p$ jusqu'\`a un certain seuil $r$, 
se ram\`ene \`a inonder les n\oe uds contenus dans une boule $B(p,r)$ centr\'ee en $p$ et de rayon $r$\footnote{On appelle boule (ferm\'ee) 
centr\'ee en $p \in \mathcal{S}$ et de rayon $r\in\mathbb R_+$, l'ensemble ${x\in \mathcal{S} | d(x,p)\leq r\}\subset \mathcal{S}}$. On la note souvent $B(p,r)$.} centr\'ee sur $d$). 
La figure \ref{fig:psearch} illustre les concepts de pSearch en montrant deux vecteurs de termes correspondant \`a des documents distincts A et B, plac\'es sur un CAN
bi-dimensionnel. L'angle $\theta$ est un indicateur de similarit\'e entre les deux documents repr\'esent\'es. La sph\`ere tangente en A circonscrit un p\'erim\`etre
de recherche. Ici, le cercle << indices >> mat\'erialise les placements possibles pour les donn\'ees.

\subsection{Autres g\'eom\'etries et discussion}
Nous avons illustr\'e sur les topologies en anneau et en tore diff\'erentes strat\'egies de placement couramment employ\'ees. D'autres
g\'eom\'etries possibles sont :   
%Avant de conclure cette section, et pour montrer la vari\'et\'e des
%g\'eom\'etries explor\'ees par les overlays P2P structur\'es dirig\'es par le routage, mentionnons les g\'eom\'etries suivantes : 
les \emph{arbres de Plaxton} \cite{plaxton99accessing}, qui ont influenc\'e la conception des solutions de DHT telles que Pastry \cite{rowstron01pastry}, Tapestry \cite{zhao04tapestry} ou Kademlia \cite{maymounkov02kademlia}; 
les \emph{graphes \`a enjambements} (<< skip graphs >>), extensions distribu\'ees et tol\'erantes aux pannes des listes \`a enjambements de Pugh \cite{pugh90skip} 
propos\'ees ind\'ependamment par SkipNet \cite{harvey03skipnet} et SkipGraph \cite{aspnes03skipgraph} ; 
les \emph{graphes en papillon} \cite{leighton92introduction}, utilis\'e notamment par Viceroy \cite{malkhi02viceroy} ;
et enfin de type \emph{graphe de de Bruijn} \cite {debruijn46combinatorial} 
(cf. Koorde \cite{kaashoek03koorde}, Broose \cite{gai04broose}, D2B \cite{fraigniaud06d2b}, \cite{loguinov03graph}) 
%Des \'etudes d\'etaill\'ees sur les diff\'erentes g\'eom\'etries sont disponibles. 
%Notre travail s'est notamment appuy\'e sur 
Pour plus de d\'etails, voir \cite{gummadi03impact, lua05survey, risson06survey}.
%Il est \`a souligner un manque que les \'etudes existantes se pr\'esentent le plus souvent sous la forme d'\'enum\'erations : peu d'\'etudes comparatives sont propos\'ees.    

Le tableau \ref{Tableau r\'ecapitulatif de diff\'erentes combinaisons strat\'egie de routage / strat\'egie de placement.} 
ordonne les solutions en fonction des strat\'egies de placement mise-en-\oe uvre (toutes les combinaisons n'\'etant pas
possibles, l'espace des possibles n'est pas uniform\'ement peupl\'e). 

La strat\'egie de placement << par partition >> fait r\'ef\'erence au cas o\`u le m\^eme espace de repr\'esentation (cart\'esien) est utilis\'e pour les n\oe uds et les donn\'ees.
%et une donn\'ee est plac\'ee sur un n\oe ud en fonction de la proximit\'e de leurs repr\'esentations dans cet espace.  
Un cas particulier \'etant celui de VoroNet, RayNet et SWAM-V qui \'eludent le probl\`eme du placement en affectant \`a un n\oe ud une donn\'ee (partant, n\oe ud et donn\'ee de m\^eme identifiant sont assimil\'es). 
\vspace{0.6cm}

\begin{tabular}{|l|c|c|c|c|c|}
\hline
 Topologie/Placement  & Hachage & Hachage         & SFC & Partition\\ 
                     &   des   & pr\'eservant la & &    des    \\
                     & donn\'ees & localit\'e      & & donn\'ees  \\
\hline
\hline
Anneau               & Chord, & MAAN & Squid & Aurelia \\
                   & Symphony &      &       &          \\
\hline
Tore d-dimensionnel  & CAN     & -               & - & SONAR  \\
\hline
Arbre de Plaxton     & Pastry, & -               & - &    -    \\
                     & Tapestry &                &  &        \\
\hline
Graphe \`a           &  -    & -              & Scrap, & SkipGraph, \\
enjambements         &      &                & ZNet\cite{shu05supporting} & SkipNet    \\
\hline
% Hypercube & Pastry, Past, & - & - & - \\
%  & Tapestry, Kademlia  & & &\\
% \hline
Graphe en papillon   & Viceroy & -           & -&   -         \\
\hline
Graphe de            & Koorde, & -           & - &   -         \\
de Bruijn            & Broose, D2B &         &  &            \\ 
\hline 
Diagramme de         & -       & -           & -& VoroNet,   \\
Voronoi               &         &             & & RayNet,   \\
                     &         &             & & SWAM-V     \\

\hline
\end{tabular} \\
\captionof{table}{TODO remettre toutes les refs \\\ Tableau r\'ecapitulatif de diff\'erentes combinaisons strat\'egie de routage / strat\'egie de placement.}
\label{Tableau r\'ecapitulatif de diff\'erentes combinaisons strat\'egie de routage / strat\'egie de placement.}
\vspace{0.6cm}

Les solutions des deux premi\`eres colonnes << hachage >> tombent dans la cat\'egorie des index unidimensionnels et sont pour la plupart 
assimilables \`a des tables de hachage distribu\'ees. 
Certaines d'entre elles autorisent les requ\^etes par intervalles.  

Les solutions des autres colonnes supportent les donn\'ees
multidimensionnelles et les requ\^etes par intervalles. SWAM-V \cite{banaei-kashani04swam} propose un algorithme de routage de requ\^etes par similarit\'e de type 
k plus proches voisins (cf. \ref{modeleRequetes}).
%De mani\`ere plus g\'en\'erale, l'\'etude de ces solutions d'index permet d'analyser les strat\'egies de placement en fonction de la dimensionnalit\'e des donn\'ees :

De mani\`ere plus g\'en\'erale, l'\'etude de ces solutions d'index permet d'\'etablir que les strat\'egies de placement de donn\'ees multidimensionnelles 
% \paragraph{Placement de donn\'ees unidimensionnelles} 
% Le placement des donn\'ees apr\`es hachage est possible pour distribuer l'ensemble des donn\'ees sur l'ensemble des n\oe uds. Cette strat\'egie 
% permet de r\'epartir la charge en termes de donn\'ees et ne n\'ecessite comme m\'eta-donn\'ee qu'une fonction de hachage. Toutefois comme nous l'avons vu,
% elle d\'etruit la localit\'e des donn\'ees et rend inefficace les requ\^ete par intervalles et de comparaison). Le placement d'intervalles () de donn\'ees d\'esigne 
% un n\oe ud responsable pour un intervalle   
% \paragraph{Placement de donn\'ees multidimensionnelles}
sont le plus souvent des variantes de l'une des cat\'egories suivantes :
\begin{itemize}

\item \textbf{R\'eduction de la dimensionalit\'e}, par le biais en g\'en\'eral d'une courbe de remplissage.
Parmi les (rares) alternatives aux SFC, une extension d'Aurelia nomm\'ee Roogle \cite{wu06roogle} lin\'earise des donn\'ees $d$-dimensionnelles en consid\'erant pour chaque donn\'ee la valeur minimale ou maximale prise par ses attributs sur l'ensemble des $d$ dimensions ;

\item \textbf{Partition de l'espace des donn\'ees} (de l'anglais << space-partitioning >>). Dans ce cas, on ne tient pas compte de la distribution du jeu de donn\'ees \`a indexer. 
L'espace de r\'ef\'erence est d\'ecoup\'e \emph{a priori} en cellules, r\'eguli\`eres ou non. Les donn\'ees sont ensuite affect\'ees aux cellules avec 
lesquelles elles ont une intersection (exemple de SONAR \cite{schutt07structured}) ; %Dans cette cat\'egorie, on trouve par exemple SONAR \cite{sch\"utt07structured}, qui repose sur topologie des pairs tr\`es similaire \`a celle de CAN \cite{ratnasamy01scalable} : un tore multidimensionnel

\item \textbf{Partition du jeu de donn\'ees}  (<< data-partitioning >>) en fonction de leur distribution dans l'espace. On cherche essentiellement ici \`a regrouper
les objets proches dans l'espace sur les m\^emes pairs (exemple de \cite{tanin07using}). 

%Cette cat\'egorie comprend notamment les solutions bas\'ees sur des arbres, abord\'ees dans la section qui suit (\ref{Conception dirig\'ee par les donn\'ees}). 
%Cette cat\'egorie comprend les solutions bas\'ees sur des SFC [REF] et les solutions bas\'ees sur des arbres
%%SkipIndex -> arbres multi : D-tree ???, R-tree \cite{guttman84r-trees}, R*-tree \cite{beckmann90r*-tree} (plutot low-d), 
\end{itemize}
%<< << << << << << << << << << << << << << <<   

%\subsubsection{Maillage de Plaxton ou hypercube}
%Routage pr\'efixe
%
%\begin{figure}[!h]
%\centering
%\includegraphics[width=0.3\textwidth]{./fig/hypercube.png}
%% Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
%\caption{Hypercube de dimension 3. Les fl\^eches indiquent le sens du routage depuis les diff\'erents n\oe uds jusqu'au n\oe ud 111.}
%\label{fig:skiplist}
%\end{figure}
%
%Le maillage de Plaxton impose un connaissance globale \emph{\emph{a priori}} lors du placement, ce qui rend les ajouts et suppression de n\oe uds. 
%
%\paragraph{Pastry}
%\paragraph{Kademlia}

%[Kademlia] : La distance utilis\'ee ici
%est une distance XOR [aka distance de Hamming ?], d\'efinie pour deux n\oe uds
%comme le r\'esultat de l'application de l'op\'erateur OU exclusif bit \`a bit
%sur leur identifiant. Chaque n\oe ud maintient une table de routage compos\'ee
%log $n$ listes de taille maximale $k$ (appel\'ee \textit{k-bucket}), o\`u la
%$i$-\`eme liste d'un n\oe ud $p$ contient jusqu'\`a $k$ n\oe uds \`a une distance
%XOR comprise entre $[2^i, 2^{i + 1}]$ de $p$. 
%En d'autres termes, le
%comportement de Kademlia est tr\`es proche de ceux de Pastry ou Tapestry.
%Seulement Kademlia acc\'el\`ere la recherche en parall\'elisant la diffusion
%d'une requ\^ete : \`a la premi\`ere it\'eration, la requ\^ete est envoy\'ee
%\`a un sous-ensemble de la liste approximant le mieux le noeux cible (et non
%pas \`a un voisin unique), puis la requ\^ete est transmise \`a un sous
%ensemble des n\oe uds retourn\'es \`a l'\'etape pr\'ec\'edente et ainsi de suite
%r\'ecursivement, jusqu'\`a terminaison de l'algorithme. Note : Kademlia a
%\'et\'e impl\'ement\'e dans des syst\`emes en production, parmi lesquels on
%peut citer le client P2P [MLDonkey] ou le client BitTorrent [Azureus].

%Tapestry, Oceanstore

% \subsubsection{Graphe \`a enjambements}
% %exemples de SkipNet et de ZNet % -> Skip Graph, SkipNet, ZNet, SCRAP
% %[TODO : \`a expliquer en plus de d\'etails ? cf ZNET, cf. resume\_skip.pdf]
% 
% Une liste \`a enjambements (\emph{skip list}) \cite{pugh89skip} est une structure de donn\'ees probabiliste de type dictionnaire, \'a base de listes cha\^in\'ees tri\'ees 
% parall\`eles. La plupart de ses op\'erations s'effectuent en $O(log n)$ avec une grande probabilit\'e.
% Une liste \`a enjambements est donc une liste cha\^in\'ee am\'elior\'ee contenant des pointeurs suppl\'ementaires 
% vers l'avant, de sorte que la recherche dans la liste puisse "sauter" (\emph{skip}) de nombreux \'el\'ements. Dans les listes probabilistes, 
% l'ajout de ces pointeurs est faite de mani\`ere al\'eatoire, pour des raisons de co\^ut des op\'erations 
% d'insertion et de suppression des \'el\'ements. 
% En tant que structure d'indexation, les listes \`a enjambements pr\'esentent l'avantage de pr\'eserver la localit\'e des donn\'ees tout en
% assurant une recherche efficace. 
% 
% \begin{figure}[!h]
% \centering
% \includegraphics[width=0.8\textwidth]{./fig/Skiplist.png}
% % Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
% \caption{Exemple de liste \`a enjambements probabiliste}
% \label{fig:skiplist}
% \end{figure}

%--------------------------------------------------
% %SkipNet \cite{harvey03skipnet} et les graphes \`a enjambements (\emph{skip graphs}) \cite{aspnes03skipgraph} sont des g\'en\'eralisations pour 
% %environnements distribu\'es des listes \`a enjambements, propos\'ees ind\'ependamment. 
% %L'id\'ee commune est d'exploiter une liste \`a enjambements pour former le graphe des pairs, tout en modifiant la structure pour l'adapter aux contraintes
% %d'un overlay P2P, entre autres : (i) permettre des recherches efficaces autrement qu'en commen\c cant par la t\^ete de la liste ; ii) r\'epartir la charge des 
% %requ\^etes sur l'ensemble des n\oe ud.  
% %Dans SkipNet \cite{harvey03skipnet} les pairs sont donc reli\'es en se servant d'une liste \`a enjambements dont les \'el\'ements sont les identifiants des pairs
% %(cha\^ines de caract\`eres repr\'esentant les IP), et que l'on fait "reboucler" en anneau. Les pairs sont organis\'es sur l'anneau selon 
% %l'ordre total sur ces identifiants. Cet anneau est ensuite d\'ecompos\'e en sous-anneaux, chaque n\oe ud choisissant au niveau $h$ son appartenance \`a un des
% %deux sous-anneaux de niveau $h+1$ de mani\`ere al\'eatoire. La s\'equence de $h$ choix d'anneau peut \^etre repr\'esent\'e pour chaque pair par un nombre binaire,
% %constituant son identifiant num\'erique. SkipNet \cite{harvey03skipnet} utilise ainsi un double espace de nommage plat pour les n\oe ud : 
% %\`a la fois num\'erique et symbolique. Si la topologie r\'esultante rappelle Chord \cite{stoica01chord}), dans SkipNet \cite{harvey03skipnet}
% %les listes sont doublement cha\^in\'ees, ce qui permet leur parcours dans les deux sens. 
% %SkipNet \cite{harvey03skipnet} permet un routage selon les identifiants symboliques comme num\'eriques. En incorporant l'identifiant 
% %symbolique d'un pair \`a l'identifiant d'une donn\'ee permet de garantir le placement de cette donn\'ee sur le pair en question. Les
% %donn\'ees partageant des pr\'efixes communs sont stock\'ees sur des segments contigus de l'anneau, assurant la propri\'et\'e de localit\'e des donn\'ees
% %n\'ecessaire au routage efficace de requ\^etes par intervalles. 
% %
% %\begin{figure}[!h]
% %\centering
% %\includegraphics[width=0.8\textwidth]{./fig/Skipnet-routing.png}
% %% Skipnet-routing.png: 500x290 pixel, 72dpi, 17.64x10.23 cm, bb=0 0 500 290
% %\caption{Exemple de tables de routage SkipNnet}
% %\label{fig:overlay skipnet}
% %\end{figure}


% \paragraph{SkipNet}
% 
% \paragraph{Utilisation d'une courbe de remplissage et partition dynamique de la courbe : exemple de ZNet}
% ZNet \cite{andrzejak02scalable} utilise un graphe \`a enjambements comme infrastructure de routage et une courbe Z TODO OU HILBERT ???? pour le placement des donn\'ees. 
% Les auteurs exploitent ainsi (i) la propri\'t\'e de localit\'e du graphe \`a enjambements pour assurer l'efficacit\'e de l'ex\'ecution des
% requ\^etes par intervalles ; ii) la propri\'et\'e de r\'eduction de la dimensionnalit\'e des r\' afin de g\'erer des donn\'ees multidimensionnelles. 
% ZNet se distingue d'autres solutions comme Squid \cite{} et SCRAP \cite{ganesan04one} (m\^eme sch\`eme de partitionnement
% des donn\'ees \`a l'aide d'une SFC et routage selon une topologie de graphe \`a enjambements que ZNet) 
% par un partitionnement dynamique de l'espace des solutions (ce qui lui permet de g\'erer des distributions variables de donn\'ees).  
% 
% 
% \subsubsection{Tesselation de Vorono\"i}
% Explor\'ee dans plusieurs travaux \cite{nahas01application,  li03localized, banaei-kashani04swam, steiner05fully, simon05distributed, beaumont07voronet, 
% dong-young07protocol}, la triangulation de Delaunay offre de s\'eduisantes propri\'et\'es
% g\'eom\'etriques pour la construction d'un r\'eseau overlay. Partant de
% donn\'ees repr\'esent\'ees dans un espace d'attributs inf\'erieur \`a trois
% dimensions ($\mathbb{R} ^2$, $\mathbb{R} ^3$), le diagramme de Delaunay induit
% permet de router simplement, de mani\`ere gloutonne, sur la base d'une
% distance euclidienne. Tandis que sa duale, le diagramme de Vorono\"{\i},
% permet un partitionnement (pavage) de l'espace des donn\'ees. Ainsi dans VoroNet \cite{beaumont07voronet}, 
% chaque cellule de Vorono\"{\i} correspond \`a une r\'egion de
% l'espace des donn\'ees g\'er\'ee par un m\^eme n\oe ud (assimil\'e au centre de
% la cellule appel\'e "objet"). Lorsqu'un n\oe ud re\c coit une
% requ\^ete pour un point $P$ (qu'il ne g\`ere pas), il la retransmet au n\oe ud
% parmi ses voisins qui minimise la distance euclidienne entre son objet et $P$.
% La recherche se termine avec le n\oe ud dont $P$ est l'objet ou qui contient
% $P$. Pour optimiser le routage, VoroNet est "petit-mondis\'e" par
% l'augmentation de son diagramme de Delaunay avec un lien suppl\'ementaire long
% par sommet [ET LES PROCHES VOISINS ?].
% %
% %TODO inserer SCHEMA
% %%, a adapter de : http://interstices.info/jcms/c\_19164/la-geometrie-des-contacts-entre-biomolecule, http://graal.ens-lyon.fr/ lmarchal/docs/slides\_VoroNet.pdf
% %
% %Un des avantages d'une topologie de Vorono\"{\i} est qu'elle permet la
% %d\'efinition de distances exotiques
% %TODO approfondir \\ %http://www-sop.inria.fr/geometrica/courses/slides/delaunay-generalisations-od.pdf].
% %Le principal d\'esavantage au regard des objectifs affich\'es par PosNet, est
% %qu'au-del\`a d'une dimension \'egale \`a 3, la complexit\'e de calcul d'un
% %diagramme de Vorono\"{\i} \'evolue exponentiellement en la dimension (en plus
% %d'\^etre sensible \`a la propagation d erreurs de calcul) \cite{boissonnat98algorithmic}. 
% %Il en d\'ecoule pour un r\'eseau overlay bas\'e sur cette
% %g\'eom\'etrie un co\^ut de maintenance prohibitif. Ce constat a amen\'e les
% %auteurs de VoroNet \`a proposer une extension de leur mod\`ele,
% %nomm\'e RayNet \cite{}. RayNet pallie cette limitation en approximant le diagramme
% %de Vorono\"{\i}, afin d'augmenter la dimensionnalit\'e tout en pr\'eservant
% %les capacit\'es de routage de mani\`ere probabiliste, avec un co\^ut de
% %maintenance de la structure raisonnable (\'evoluant lin\'eairement en la
% %dimension.
% %
% %\begin{figure}[!h]
% %\centering
% %\includegraphics[width=0.6\textwidth]{./fig/chord.png}
% %% Skipnet-routing.png: 500x290 pixel, 72dpi, 17.64x10.23 cm, bb=0 0 500 290
% %\caption{Exemple de tables de routage SkipNnet}
% %\label{fig: Un reseau Chord 6 bits de 8 n\oe uds et 4 cl\'es}
% %\end{figure}
% %

%\subsubsection{R\'ecapitulatif et discussion sur l'approche dirig\'ee routage}
Comme le montrent les exemples cit\'es, les solutions bas\'ees DHT occupent une place importante dans la conception dirig\'ee par le routage d'overlays P2P 
(et de mani\`ere g\'en\'erale dans la conception d'overlays P2P structur\'es). 
Reposant sur des topologies logiques auto-organisatrices, offrant d'excellentes performances,
garantissant enfin analytiquement une taille des routes et un nombre de messages \'echang\'es born\'es,
les DHT repr\'esentent en effet une strat\'egie de routage s\'eduisante pour le stockage et l'indexation distribu\'es. 
Dans le cas d'applications pouvant se satisfaire de requ\^etes par mots-cl\'es, les DHT constituent des solutions d'index
particuli\`erement efficaces. 

Les index bas\'es DHT sont n\'eanmoins inadapt\'es \`a nos objectifs.
D'une part, les DHT sont des index unidimensionnels car ils indexent par cl\'e (ce qui contrevient \`a notre crit\`ere 3). 
%Pour la gestion de requ\^etes multidimensionnelles, l'utilisation de multiples index unidimensionnels 
% entra\^ine l'extraction de donn\'ees en nombre inutilement grand \`a moins d'avoir la connaissance, difficilement accessible. 
Ensuite la principale propri\'et\'e des DHT, qui est de permettre la r\'epartition de la charge, les rend 
impropres \`a la r\'esolution efficace de requ\^etes par intervalles et de comparaison (viole notre crit\`ere 4).
En effet, l'utilisation de fonctions de hachage dispersant al\'eatoirement les donn\'ees sur les n\oe uds conduit \`a la perte de l'information de localit\'e.
Une approche na\"ive de r\'esolution d'une requ\^ete par intervalle qui consisterait \`a employer une DHT
% juxtaposer les 
% index unidimensionnels, mais cela aurait pour cons\'equence de provoquer l'extraction d'un nombre de donn\'ees inutilement \'elev\'e. Une autre possibilit\'e,
% tout aussi inapropri\'ee serait d'ex\'ecuter sur un index unidimen
pour ex\'ecuter une requ\^ete exacte par valeur discr\^ete contenue dans l'intervalle concern\'e n'est pas satisfaisante. 

De nombreux travaux proposent d'\'etendre les fonctionnalit\'es d'une DHT en se servant de celle-ci comme infrastructure de routage 
et en lui superposant des m\'ecanismes, notamment pour la gestion de requ\^etes par intervalles. 
Concernant le support de requ\^etes par intervalles, ces m\'ecanismes (se traduisant en strat\'egies de placement) sont toutefois imparfaits : partition de l'espace des donn\'ees
\emph{a priori} n\'ecessitant une connaissance globale de celui-ci, indexation de solutions limit\'ees \`a des requ\^etes d'intervalles pr\'e-d\'efinies et calcul\'ees, 
probl\`eme de localit\'e des donn\'ees d\'eplac\'e au niveau des intervalles (placement d'intervalles contigus sur des pairs dispers\'es), etc. 
De plus, l'approche en couches a une incidence sur les performances de ces syst\`emes, en comparaison de solutions offrant un support natif aux requ\^etes par intervalles. 
Chawathe \emph{et al.} \cite{chawathe05case} font une \'etude de performances sur des applications
en grandeur r\'eelle utilisant une courbe Z au-dessus d'OpenDHT \cite{openDHT} et rel\`event des temps de r\'eponse de 2 \`a 4 secondes par requ\^ete pour moins d'une trentaine de n\oe uds. 
Ainsi, les avantages des overlay bas\'es DHT dans la r\'esolution de requ\^etes exactes sont consid\'erablement r\'eduits s'agissant des requ\^etes par intervalles. 
Lorsque les intervalles sont suffisamment ouverts ou grands, le co\^ut d'une recherche peut devenir 
lin\'eaire, faisant perdre le b\'en\'efice d'une recherche en temps logarithmique typiquement offert par le mod\`ele bas\'e DHT. 

% La conception d'overlay P2P dirig\'ee par les donn\'ees, en privil\'egiant une organisation \emph{s\'emantique} des donn\'ees 
% fonction du type de donn\'ees et de requ\^etes d\'esir\'ees, se donne pour objectif de d\'epasser les limitations des solutions bas\'ees DHT.  
Apr\'es avoir \'etudi\'e la conception d'overlay P2P dirig\'ee par le routage, qui privil\'egie les propri\'et\'es math\'etiques de topologies de routage \`a 
l'expressivit\'e des requ\^etes, nous consid\'erons donc la conception d'overlay dirig\'ee par les donn\'ees, qui privil\'egie une organisation des
donn\'ees pr\'eservant la localit\'e spatiale. 

% La sous-section suivante d\'etaille comment en partant des donn\'ees, les organiser en fonction des requ\^etes d\'esir\'ees, 
% puis les distribuer afin d'assurer un routage efficace des requ\^etes. 

%cavagna09framework,
%nahsa01application, 
%simon05distributed, 
%[N. de Bruijn. A combinatorial problem. Proc. Kominklitjke Nederlandse Akademie van Wetenschappen, 49:758 764, 1946] 
%Pour une pr\'esentation de ces topologies de routage et de leurs applications, nous renvoyons le lecteur aux \'etats de l'art \cite{}. 

\section{Etat de l'art : Conception dirig\'ee par les donn\'ees d'overlays P2P structur\'es} \label{sec:Etat de l'art : Conception dirig\'ee par les donn\'ees d'overlays P2P structur\'es}

Dans ces approches, le choix de la structure d'indexation des donn\'ees d\'etermine la solution. 
Les donn\'ees sont organis\'ees, en fonction de leur type et des requ\^etes d\'esir\'ees, au sein d'une structure globale qui permet ddes recherches efficaces. 
Cette structure de donn\'ees est ensuite distribu\'ee sur les pairs de l'overlay.  

La figure \ref{fig:conceptionDirigeeDonnees} illustre les \'etapes g\'en\'eriques de conception d'un overlay P2P dirig\'ee par les donn\'ees.
Lors de l'\'etape I, les donn\'ees de $g\langle \mathcal{O} \rangle$ sont organis\'ees dans une structure de donn\'ees $S$ adapt\'ee au type de requ\^etes vis\'e. Lors de l'\'etape II, l'application de la fonction $p$ associe chaque donn\'ee \`a un n\oe ud. Lors de l'\'etape III, la topologie des n\oe uds est d\'eduite de la structure de donn\'ees et de la r\'epartition des donn\'ees sur les pairs.
%d\'eduite de la r\'epartition des donn\'ees
Un n\oe ud $n$ et connect\'e \`a un n\oe ud $m$ si et seulement si une donn\'ee de $p^{-1}(n)$ est associ\'ee \`a une donn\'ee de $p^{-1}(m)$ dans $S$. Les \'etapes II et III distribuent la structure de donn\'ees sur les n\oe uds de l'overlay. 


\begin{figure}[!h]
	\centering
	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
		\includegraphics[width=0.6\textwidth]{fig/conceptionDirigeeDonnees.png}
		\caption{Processus g\'en\'erique de conception d'un overlay en partant des donn\'ees.}
	\label{fig:conceptionDirigeeDonnees}
\end{figure}


% Nous nous int\'eressons dans cette dissertation aux applications qui, utilisant des m\'ethodes d'extraction d'attributs, reposent
% sur une repr\'esentation de leurs donn\'ees sous forme de vecteurs d'attributs dans un espace \`a $d$ dimensions ($d$ pouvant 
% \^etre arbitrairement grand). Comme soulign\'e dans notre \'etude des approches connexes, l'indexation de ce type de donn\'ees a \'et\'e largement \'etudi\'e en 
% environnement centralis\'e. Or de la m\^eme fa\c con que la conception d'overlays P2P
% dirig\'ee par le routage s'inspire fortement des graphes d'interconnexion utilis\'es en architecture parall\`ele, 

Une approche efficace et commune pour la recherche de donn\'ees est de hi\'erarchiser l'espace de recherche, 
typiquement \`a l'aide d'arbres.  
Les arbres pr\'esentent plusieurs avantages. 
D'une part les donn\'ees qui interviennent dans de nombreux probl\`emes sont naturellement structur\'ees en arbres 
(hi\'erarchies d'objets, choix et d\'ecisions, arbres syntaxiques, etc.). 
D'autre part, les arbres supportent les recherches multidimensionnelles bas\'ees sur la localit\'e. 
Enfin, comparativement \`a d'autres structures de donn\'ees, les algorithmes associ\'es aux arbres de recherche (algorithmes de parcours, d'insertion, etc.) 
sont d'une grande efficacit\'e. 
%leur structure hi\'erarchique en fait des candidats tout d\'esign\'es pour un routage efficace \cite{gummadi03impact}. 
Les arbres sont largement utilis\'es dans le domaine des m\'ethodes d'acc\`es spatiales (cf. \ref{subsubsec:Des SGBD aux bases de donn\'ees spatiales}. 
La tr\`es grande majorit\'e des solutions d'index P2P dirig\'ees par les donn\'ees consiste \`a adapter ces structures de 
donn\'ees\footnote{Du fait de cette sur-repr\'esentation, nous faisons le choix de laisser de c\^ot\'e d'autres SAM tels que les fichiers de grille \ref{nievergelt81grid}.}.

% Nous avons choisi d'illustrer l'utilisation d'arbres dans les index P2P en d\'eclinant les travaux men\'es autour de l'un d'eux en particulier 
% : BATON\cite{jagadish05baton}. 
% %La raison en est d'une part que l'espace des solutions est restreint : les sch\`emes de distribution d'arbres sur des overlays (non structur\'es en DHT) sont encore r\'ecents. 
Plut\^ot que d'\'enum\'erer tous les types d'arbres figurant dans les solutions d'index P2P existantes, nous proposons une \'etude didactique %en accordant une place pr\'epond\'erante \`a l'une d'elle : 
se basant notamment sur la solution BATON\cite{jagadish05baton}. 
BATON, qui supporte dans sa version originelle les requ\^etes unidimensionnelles par intervalles, 
sert en effet de point de d\'epart \`a une s\'erie de travaux qui en \'etendent successivement les fonctionnalit\'es : support des requ\^etes multidimensionnelles, exactes, par intervalles (BATON* et VBI), puis skyline (avec SSP et iSky). 
L'\'etude des modifications propos\'ees permet selon nous de donner un aper\c cu de la gestion sur des arbres des probl\'ematiques d\'ej\`a 
mentionn\'ees : support des donn\'ees mutl-dimensionnelles, placement des donn\'ees pr\'eservant leur localit\'e spatiales, 
compromis co\^ut de recherche / co\^ut de maintenance, compromis fiabilit\'e / co\^ut de maintenance, etc. 

%Bien entendu, nous examinons aussi les autres travaux qui nous semblent pertinents, en-dehors de BATON. 
En plus de BATON et de ses extensions, dans la suite 
nous passons en revue dans cette derni\`ere section les index P2P bas\'ees sur des arbres, dans un ordre croissant de complexit\'e, avant de clore le chapitre sur une synth\`ese critique.   
% Choississant d'adresser la probl\`ematique du support natif de donn\'ees multidimensionnelles par d'autres biais que la r\'eduction de la dimensionalit\'e
% ou la partition de l'espace, ces solutions 
% empruntent au domaine des SAM des structures d'arbres et s'attellent \`a la question de leur adaptation \`a un contexte d\'ecentralis\'e. 

%La structure la plus populaire/usit\'ee de cette troisi\`eme la premi\`ere cat\'egorie est le
%R-Tree, dont un exemple est donn\'e dans la figure ??? [SCHEMA : reprendre  
%Bases de donn\'ees spatio-temporelles  , C\'edric du Mouza et Philippe
%Rigaux]. Le R-Tree est construit \`a partir d'une hi\'erarchie de rectangles
%contenus les uns dans les autres, les feuilles repr\'esentant des rectangles
%minimaux englobant la g\'eom\'etrie des objets spatiaux. Les requ\^etes,
%parcourant l'arbre depuis la racine, sont achemin\'ees en profondeur jusqu'au
%dernier n\oe ud enfant qui le contient. [COMPLETER : efficacit\'e des R tree].
%L'adaptation des R-Tree au contexte P2P soul\`eve des probl\'ematiques, telles
%que ???. Plusieurs travaux se sont attel\'es \`a leur r\'esolution, telles que
%[???]. [COMPLETER : en d\'etailler quelques un]
%\begin{itemize}
%\item [DHR-Tree] (Distributed Hilbert R-Tree) est une extension
%   multidimensionnelle de l'overlay structur\'e P-Tree (cf. \ref{p-tree}). La topologie est celle de P-Tree
%   (d\'edi\'e au donn\'ees unidimensionnelles). Les n\oe uds g\`ere une
%   r\'egion de l'espace des solutions, correspondant \`a une
%   \textit{minimal bounding box,} et sont identifi\'es par la valeur de
%   Hilbert correspondant au milieu de cette bo\^{\i}te englobante.
%\item [P2PR-Tree par Mondal] : maintenance pas d\'etaill\'ee ?
%\item [SC-Tree de Mouza]  
%\item [SCRAP, MURK] d\'eploient la m\^eme approche consistant \`a   aplatir 
% des donn\'ees multidimensionnelles gr\^ace \`a une SFC, \`a les
% partitionner puis \`a affecter les partitions aux n\oe uds d'une solution
% d'overlay unidimensionnel pr\'e-existante. L'originalit\'e de l'approche des
% auteurs r\'esde dans leur approche exp\'erimentale syst\'ematique. Ainsi
% SCRAP
%\item [R*-tree]
%\item VBI-Tree : 
%\end{itemize}


% \item Arbre P : exemple de DHR-ree. DHR-Tree ou (Distributed Hilbert R-Tree) est une extension multidimensionnelle de l'overlay structur\'e P-Tree (cf. \ref{p-tree}). 
% La topologie est celle de P-Tree (d\'edi\'e au donn\'ees unidimensionnelles). Les n\oe uds g\`ere une r\'egion de l'espace des solutions, correspondant \`a une
% b et sont identifi\'es par la valeur de Hilbert correspondant au milieu de cette bo\^ite englobante.

% \begin{tabular}{|c|c|c|}
% \hline
% Overlay / Type d'arbre  &  Quaternaire & K-D & B+\\
% \hline
% \hline
% Chord & \cite{tanin07using} & \cite{gao07efficient} & P-Tree \cite{crainiceanu04querying}\\
% \hline
% CAN & \cite{zuo08can-qtree} & Murk \cite{ganesan04one} &\\
% \hline
% Skip graph & & &
% \hline
% \end{tabular}
% \captionof{table}{Tableau r\'ecapitulatif des symboles}
% \label{Tableau r\'ecapitulatif des symboles}
% \vspace{0.6cm}


%\subsubsection{Etude de quelques solutions d'index P2P bas\'es sur des arbres} \label{Solutions d'index P2P bas\'es sur des arbres}

% \paragraph{Requ\^etes par intervalles}
% BATON \cite{jagadish05baton} constitue peut-\^etre la premi\`ere tentative de distribution d'un arbre sur r\'eseau P2P. 
%Partant d'un arbre binaire, Jagadish \emph{\emph{\emph{\emph{et al.}}}}
% ??????????



% \paragraph{Requ\^etes de comparaison}
% 
% \paragraph{Requ\^etes skyline}
% % -> BITPEER, isky, BATON Skyline ?

\paragraph{Requ\^etes unidimensionnelles par intervalles}
BATON (BAlanced Tree Overlay Network) constitue une des premi\`eres propositions consistant \`a distribuer un arbre sur un overlay.
%En tant que tel, et malgr\'e son caract\`ere unidimensionnel, nous lui accordons une place dans cette section. 
BATON est un arbre binaire de recherche (ABR) \'equilibr\'e distribu\'e, 
permettant de r\'esoudre des requ\^etes unidimensionnelles par intervalles avec un co\^ut logarithmique en la taille de l'overlay. 
Les sommets de l'arbre sont distribu\'es sur les pairs selon une bijection 
(les termes sommet, pair et n\oe ud sont consid\'er\'es interchangeables dans la suite). 
%L'espace des donn\'ees est d\'ecoup\'e en intervalles. Chaque intervalle est associ\'e \`a un n\oe ud et ins\'er\'e dans l'arbre selon les r\`egles de construction d'un ABR.  
%En plus de l'intervalle qui lui est associ\'e, un n\oe ud poss\`ede l'information des intervalles couverts par ses voisins. 
Les voisins d'un n\oe ud sont de quatre types : le n\oe ud p\`ere, les n\oe uds fils, les n\oe uds adjacents dans l'ordre infixe\footnote{Le parcours dans l'ordre infixe explore l'espace des donn\'ees dans l'ordre des valeurs croissantes.}, 
et des n\oe uds parmi les n\oe uds de m\^eme profondeur (que nous appelons liens transverses). 
Pour une profondeur $L$ donn\'ee, la position des n\oe uds est num\'erot\'ee de gauche \`a droite, de $1$ \`a $2^L$ et chaque n\oe ud re\c coit le num\'ero correspondant \`a sa position. 
%%Il lui est de plus associ\'e une profondeur et un ientifiant num\'erique. 
Pour un n\oe ud de profondeur $F$ et num\'erot\'e $N$, 
les r\'ef\'erences aux n\oe uds voisins de m\^eme profondeur sont conserv\'ees dans deux tables, gauche et droite.
%, selon que leurs num\'eros sont resp. inf\'erieurs ou sup\'erieurs \`a $N$. 
Les entr\'ees de la table gauche (resp. droite) sont form\'ees des n\oe uds de profondeur $F$ et de position $N-2^x$ (resp. $N+2^x$), pour tout
$x>0$ valide. 
%Dans la table gauche (droite) du n\oe ud $F:N$, l'entr\'ee $j$ correspond au n\oe ud de profondeur $F$ dont le num\'ero correspond \`a : $N-2^{j-1}$  ($N+2^{j-1}$) 
%(en l'absence d'un n\oe ud portant le num\'ero calcul\'e, la r\'ef\'erence est positionn\'ee \`a $null$).
La figure \ref{fig:baton} d\'etaille l'\'etat d'un n\oe ud dans un overlay BATON, avec la composition des tables de routage gauche et droite. 

\begin{figure}[!h]
\centering
\includegraphics[width=0.8\textwidth]{./fig/baton.JPG}
% Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
%\caption{Exemple d'arbre R en 2 dimensions (adapt\'e de \cite{coursenst})}
\caption{Instance de l'overlay BATON avec le d\'etail du voisinage du n\oe ud d'\'etiquette $m$.}
\label{fig:baton}
\end{figure}


Chaque n\oe ud est associ\'e \`a un intervalle de donn\'ees et maintient l'information de l'intervalle couvert par ses voisins. 
Lorsqu'un nouveau n\oe ud est ins\'er\'e en tant que feuille (resp. gauche ou droite), un intervalle continu de valeurs lui est affect\'e, 
correspondant \`a la moiti\'e de l'intervalle d\'etenu par son p\`ere (resp. moiti\'e
inf\'erieure ou sup\'erieure). En d'autres termes, BATON op\`ere une partition du jeu de donn\'ees. 
Le choix de la position d'un nouveau n\oe ud respecte le crit\`ere d'\'equilibre total : le niveau le plus bas doit \^etre totalement rempli avant qu'un nouveau niveau soit cr\'e\'e. 

Le routage des requ\^etes par intervalles exploite la propri\'et\'e du parcours infixe de l'arbre.  
Pour un intervalle donn\'e, 
BATON commence par localiser sa borne inf\'erieure (en \'emettant la requ\^ete exacte correspondante), 
puis poursuit la recherche en suivant les liens d'adjacence jusqu'\`a
localisation de la borne sup\'erieure. Pour une requ\^ete exacte, BATON applique la strat\'egie de routage de Chord \cite{stoica01chord} : 
la requ\^ete est transmise, via un lien transverse, 
au n\oe ud le plus \'eloign\'e dont la borne sup\'erieure soit inf\'erieure \`a la cl\'e. Si un tel n\oe ud n'existe pas, 
la requ\^ete est transmise \`a un n\oe ud parent, fils ou adjacent. 
%Enfin, BATON pr\'evoit un m\'ecanisme de r\'epartition de charge dynamique entre voisins. 


% La solution d\'ecrite dans \cite{liau04efficient} partage avec BATON la structure d'arbre avec une bijection entre sommets de l'arbre et pairs. La diff\'erence 
% tient \`a ???. De plus, des liens sur des n\oe uds de m\^eme profondeur cr\'eant des cycles, nous pouvons argumenter que la structure propos\'ee en \cite{liau04efficient} est
% en fait un graphe. Ce qui en fait, \`a notre connaissance, le seul exemple avec PosNet de graphe distribu\'e sur un overlay P2P. 


% \item proches de : P-tree (B+ sur Chord), P-grid (trie), Liau (graphe)
% \item Avantages : gestion data skew, robustesse
% \item Limitations : donn\'ees unidimensionnelles uniquement / requ\^etes exactes et par intervalles mais pas plus / exactement 1 seul chemin entre deux n\oe uds / 
% \end{itemize}
% 
% Autres solutions comparables :  P-Grid \cite{} (arbre trie ou lexicographique), \cite{liau04efficient} (graphe). 


% Se rapprochant de la structure de donn\'ee adopt\'ee dans PosNet, \cite{liau04efficient} distribue sur un ensemble de n\oe uds une structure arborescente 
% \footnote{Si la structure poss\`ede une racine unique, elle poss\`ede des cycles. C'est donc techniquement un graphe, sym\'etrique.}, offrant un support
% \`a des requ\^etes exactes ou par intervalles sur des donn\'ees unidimensionnelles. 
% %sym\'etrique en fait, c'est-\`a-dire un graphe orient\'e dans lequel pour chaque paire de n\oe uds $(s,t)$, il existe autant d'arcs de la forme $(s,t)$ que $(t,s)$).
% Les donn\'ees sont repr\'esent\'ees dans un espace lin\'eaire. Chaque n\oe ud de la structure est responsable d'un intervalle continu de valeurs de cet espace et stocke 
% l'ensemble des donn\'ees \`a valeur dans cet espace. Par ailleurs, les n\oe uds sont connect\'es. Le voisinage d'un n\oe ud est compos\'e de : 
% \begin{itemize}
% \item son \emph{p\`ere} (s'il n'est pas la racine)
% \item de l'ensemble de ses \emph{fils} (s'il n'est pas une feuille) et de l'intervalle de donn\'ees supervis\'e par chacun de son ou ses fils
% \item d'un \emph{parent} (<< sibling >>), soit un autre fils de son p\`ere (s'il existe)
% \item d'un \emph{voisin}, c'est-\`a-dire un autre n\oe ud du m\^eme niveau qui n'a pas le m\^eme p\`ere (s'il existe)
% \end{itemize}
% %\vspace{0.6cm}
% La figure \ref{fig:liau} montre sur un exemple les diff\'erents types de voisins possibles pour un n\oe ud. 
% Si nous prenons pour exemple le n\oe ud $(113)$, celui-ci connait ${(11),(112),(121)}$ : $(11)$ est son p\`ere (ainsi que le p\`ere de $(111)$ et $(112)$), 
% $(112)$ est un parent de $(113)$ et $(121)$ un de ses voisins.   
% 
% \begin{figure}[!h]
% \centering
% \includegraphics[width=0.6\textwidth]{./fig/liau.png}
% % Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
% %\caption{Exemple d'arbre R en 2 dimensions (adapt\'e de \cite{coursenst})}
% \caption{Instance de la structure de donn\'ees propos\'ee par \cite{liau04efficient}.}
% \label{fig:liau}
% \end{figure}
% 
% La distribution de cette structure est simple : chaque sommet du graphe est affect\'e \`a un n\oe ud de l'overlay 
% (dans la suite nous assimilons un n\oe ud de l'overlay au n\oe ud du graphe associ\'e, par souci de concision). 
% Le routage d'une requ\^ete se ram\`ene donc \`a un routage dans 

\paragraph{Requ\^etes multidimensionnelles par intervalles}
Les auteurs de BATON, Jagadish \emph{et al.}, ont \'etendu leur solution initiale dans deux directions.
La premi\`ere direction, d\'ecrite sous le nom de BATON* dans \cite{jagadish06speeding}, modifie BATON en autorisant un degr\'e des n\oe uds sup\'erieur \`a 2. 
Autrement dit, BATON* abandonne l'arbre binaire de recherche de BATON au b\'en\'efice d'un arbre $k$-aire (g\'en\'eralisation de l'arbre binaire o\`u chaque 
n\oe ud est de degr\'e au plus $k$). 
Le but recherch\'e est l'augmentation des performances de recherche : par-rapport \`a BATON, le co\^ut des recherches est ramen\'e de $O(log_2N)$ \`a $O(log_mN)$, tandis que
 le co\^ut de maintenance des tables de routage augmente l\'eg\`erement et passe de $O(log_2N)$ \`a $O(mlog_mN)$. 
L'augmentation du degr\'e b\'en\'eficie \'egalement \`a la tol\'erance aux pannes de BATON*. En effet, celle-ci est directement li\'ee au nombre de
n\oe ud pouvant d\'efaillir avant que le graphe des pairs ne cesse d'\^etre connexe. 
Le crit\`ere d'\'equilibre est conserv\'e. Afin de ma\^itriser l'augmentation en taille des tables de routage entra\^in\'ee 
par l'augmentation du degr\'e du graphe, BATON* inclut un mod\`ele de co\^ut permettant d'optimiser le choix du degr\'e en fonction des besoins applicatifs.  
Une autre incidence du passage \`a l'arbre $k$-aire sur les tables de routage : la lin\'earisation par parcours infixe n'\'etant plus possible, 
la notion de voisins adjacents n'a plus court. La route d'une requ\^ete n'emprunte plus que des liens transverses ou entre parent-fils.   

Les auteurs ajoutent le support requ\^etes multidimensionnelles en adoptant l'approche de MAAN ou Mercury (vus 
en \ref{sec:Etat de l'art : Conception dirig\'ee par le routage d'overlays P2P structur\'es}) : 
(1) construire un index par dimension, (ii) d\'ecomposer la requ\^ete multidimensionnelle en requ\^etes unidimensionnelles, (iii) ex\'ecuter les sous-requ\^etes
dans les index unidimensionnels en exploitant la s\'electivit\'e des attributs
\footnote{On rappelle ici la notion de s\'electivit\'e, que nous avons d\'efinie comme le rapport du nombre de valeurs distinctes d'un attribut au nombre de donn\'ees.} 
pour optimiser les recherches, (iv)
calculer l'intersection des solutions sur une dimension retourn\'ees par chaque index, afin d'obtenir les solutions v\'erifiant la conjonction de pr\'edicats de la requ\^ete initiale. 
%Pour un commentaire surcette approche, cf. \ref{sec:Etat de l'art : Conception dirig\'ee par le routage d'overlays P2P structur\'es}. 

% r\'eduire la dimensionalit\'e du probl\`eme en 
% exploitant la s\'electivit\'e des attributs\footnote{On appelle ici s\'electivit� le rapport du nombre de valeurs distinctes d'un attribut au nombre de donn\'ees)}.
% Ainsi BATON* s\'electionne les $(1,\ldots,h)$ attributs les plus discriminants et construit un index unidimensionnel par attribut. L'espace des attributs restants est lin\'earis\'e
% en utilisant une courbe de remplissage et les donn\'ees unidimensionnelles ainsi obtenues sont plac\'ees dans une $(h+1)$-\`eme instance de BATON*.
% Le r\'esultat d'une requ\^ete multidimensionnelle est obtenu en ((i) d\'ecomposant la requ\^ete en sous-requ\^etes unidimensionnelles, (ii) en r\'esolvant une sous-requ\^ete, 
% de pr\'ef\'erence portant sur un attribut discriminant et donc directement ex\'ecutable sur un des $h$ index unidimensionnels, (iii) en filtrant les solutions ainsi 
% obtenues \`a l'aide des sous-requ\^etes restantes

\paragraph{}La seconde direction suivie par les auteurs de BATON, d\'ecrite sous le nom de << Virtual Binary Index >> ou VBI dans \cite{jagadish06vbi-tree}, 
est de proposer un framework g\'en\'erique de conception d'index P2P \`a partir d'arbres multi-dimensionnels reposant sur une partition hi\'erarchique des donn\'ees 
(tel que l'arbre R, vu en \ref{subsubsec:Des SGBD aux bases de donn\'ees spatiales}). 
VBI s'\'eloigne assez de BATON. Notamment les n\oe uds VBI internes sont d\'edi\'es au routage uniquement et la topologie de l'overlay ne peut 
plus se d\'eduire directement de l'arbre par une bijection entre les sommets et les pairs. 
Chaque n\oe ud interne est associ\'e \`a une bo\^ite englobante contenant les bo\^ites de ses sous-arbres (hyper-rectangles dans le cas de l'arbre R, 
ou l'\'equivalent pour les autres types d'arbres). Chaque feuille est associ\'ee \`a une bo\^ite englobante minimale (idem). La figure \ref{fig:vbi} illustre
la partition d'un espace de donn\'ees bidimensionnel et l'arbre VBI qui en est inf\'er\'e. 
La table de routage d'un n\oe ud VBI reprend les m\^emes voisins que celle d'un n\oe ud BATON. 
Mais d\'esormais, au lieu de conserver pour chaque voisin l'information de la r\'egion supervis\'es, un n\oe ud VBI ne conserve l'information que pour ses fils. En revanche, il stocke en plus la connaissance de la r\'egion supervis\'ee par chacun de ses ant\'ec\'edents. 

% \begin{floatingfigure}[option]{8cm}
% 	\centering
% 	%\includegraphics[width=0.6\textwidth]{./fig/quadtree_ang.jpg}
% 		\includegraphics[width=0.3\textwidth]{fig/vbi}
% 		\caption{Placement de donn\'ees bidimensionnelles dans une instance de VBI et trace du routage d'une requ\^ete exacte.}
% \label{fig:fonctionnementIndex}
% \end{floatingfigure}

Le traitement d'une requ\^ete de recherche pour un n\oe ud VBI, que ce soit pour les requ\^etes exactes ou par intervalles, est le suivant. 
Si un n\oe ud VBI re\c coit une requ\^ete contenue par sa bo\^ite, il essaie de raffiner la requ\^ete en cherchant \`a transmettre la requ\^ete \`a un de ses fils. Si la bo\^ite 
d'un de ses fils contient la requ\^ete alors la requ\^ete lui est transmise. Sinon le n\oe ud courant la traite. En revanche, si la requ\^ete n'est pas contenue dans la bo\^ite du 
n\oe ud courant, alors celui-ci consulte les bo\^ites de ses anc\^etres pour d\'eterminer l'anc\^etre $a$ qui contient la requ\^ete (quitte \`a remonter jusqu'\`a la racine, 
qui couvre l'espace entier des donn\'ees). 
Mais la requ\^ete n'est remont\'ee vers $a$ que si le n\oe ud ne poss\`ede pas de lien transverse vers un sous-arbre de $a$. C'est le cas si le n\oe ud courant est une feuille. 
Sinon, la requ\^ete est transmise \`a un voisin du sous-arbre de $a$, lequel it\`ere la m\^eme proc\'edure (cf. \ref{fig:vbi}).
La diff\'erence de traitement entre une requ\^ete par intervalles et une requ\^ete exacte tient essentiellement au parall\'elisme du traitement : \`a chaque saut dans l'overlay, une requ\^ete par intervalle peut \^etre 
transmise \`a plusieurs n\oe uds.  

\begin{figure}[!h]
\centering
\includegraphics[width=0.6\textwidth]{./fig/vbi}
% Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
%\caption{Exemple d'arbre R en 2 dimensions (adapt\'e de \cite{coursenst})}
\caption{Placement de donn\'ees bidimensionnelles dans une instance de VBI et trace du routage d'une requ\^ete exacte}
\label{fig:vbi}
\end{figure}  
 
\paragraph{}
Un autre travail \'etendant BATON est \cite{wang07efficient}. Leur solution pr\'esente l'int\'er\^et de 
supporter, outre les requ\^etes multidimensionnelles par intervalles, les requ\^etes skyline. Nous d\'ecrivons ici les premi\`eres ; les secondes sont d\'ecrites au 
paragraphe suivant. 

Wang \emph{et al.} conservent l'arbre binaire de la version originelle de BATON et lui adaptent 
un espace des donn\'ees multidimensionnel en utilisant une courbe de remplissage Z. 
L'espace des donn\'ees, de dimension $d$, est d\'ecoup\'e en r\'egions \`a l'aide d'hyperplans de dimensions $d-1$, en alternant les directions entre les dimensions. 
Chaque r\'egion est identifi\'ee par une cl\'e, qui transcrit sa position relative aux hyperplans : 
pour une cl\'e donn\'ee, le $i$-\`eme bit est \'egal \`a $1$ (resp. $0$) si la r\'egion associ\'ee est sup\'erieure (resp. inf\'erieure) pour la $i$-\`eme coordonn\'ee. 
Les informations maintenue par un n\oe ud de leur structure sont de deux sortes : (i) des informations li\'ees \`a la r\'egion supervis\'ee ; (ii) 
des informations de routage en tant que sommet dans un overlay BATON. 
Les informations sur la r\'egion sont : (a) sa cl\'e ;  (b) le tableau d'hyperplans contigus (d\'esign\'e en anglais 
par << split history >>), avec des entr\'ees de la forme $(SplitPos,SplitDim)$ o\`u 
$SplitDim$ est une dimension et $SplitPos$ la coordonn\'ee du plan selon cette dimension ; 
(c) l'intervalle de valeurs contenu dans la r\'egion. 
%, (d) la dimension correspondant \`a la direction de l'hyperplan de la prochaine partition. 

Les cl\'es sont plac\'ees dans l'arbre BATON de telle mani\`ere \`a faire correspondre l'ordre total des r\'egions travers\'ees par la courbe de remplissage et 
l'ordre total sur les r\'egions obtenu lors du parcours infixe de l'arbre BATON. 
La figure \ref{fig:ssp} donne un exemple d'\'etat de n\oe ud dans une instance d'overlay SSP, en tant que section de la courbe (en haut) et en tant que sommet de l'arbre (en bas). 

% \begin{figure}[!h]
% \centering
% \includegraphics[width=0.4\textwidth]{./fig/isky}
% % Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
% %\caption{Exemple d'arbre R en 2 dimensions (adapt\'e de \cite{coursenst})}
% \caption{Construction d'une instance de l'overlay iSky.}
% \label{fig:isky}
% \end{figure}  

\begin{figure}
\centerline{\subfigure[Partition des donn\'ees et nommage des r\'egions]{\includegraphics[width=0.4\textwidth]{./fig/isky_haut}}
	    \hspace{1cm}
 	    \subfigure[Placement des cl\'es sur BATON]{\includegraphics[width=0.4\textwidth]{./fig/isky_bas}}}
\caption{Construction d'une instance de l'overlay de \cite{wang07efficient} (via \cite{wang07efficient}).}
\label{fig:ssp}
\end{figure}

%Dans l'arbre qui en r\'esulte, le sous-arbre droit correpond aux r\'egions 
%du << m\^eme >> c\^ot\'e de l'hyperplan par-rapport \`a la r\'egion associ\'ee au n\oe du courant, le sous-arbre gauche aux r\'egions de l'autre c\^ot\'e.

Sur r\'eception d'une requ\^ete exacte ou par intervalles, un n\oe ud commence par v\'erifier si l'objet recherch\'e est couvert par sa propre r\'egion. 
Sinon, il consid\`ere parmi son historique 
l'hyperplan orthogonal avec la direction minimisant la distance avec l'objet recherch\'e. Soit $j$ la position dans le tableau de cet hyperplan, 
le n\oe ud courant choisit alors un voisin auquel transmettre la requ\^ete parmi ceux dont la cl\'e diff\`ere pour le $j$-\`eme bit (et \`a (1,\ldots,j-1) premiers bits constants). 
Soulignons l'analogie avec le routage par pr\'efixes (cf. routage Plaxton \cite{plaxton99accessing}). 

% Pour une critique : \cite{zhang07sdi}

% Dans la cat\'egorie des solutions d'index P2P bas\'ees sur des arbres et supportant des requ\^etes de type spatiales, mentionnons P2PR-tree \cite{mondal04p2pr-tree}, qui
%  distribue un arbre R sur un overlay. %L'arbre R a \'et\'e d\'ecrit dans la section \ref{subsubsec:Des SGBD aux bases de donn\'ees spatiales}. 
% P2PR-tree construit un arbre R dont les feuilles se composent des rectangles minimaux englobants les donn\'ees supervis\'ees par un pair. L'espace des donn\'ees
% est d\'ecompos\'e statiquement 
% La figure \ref{fig:p2pr-tree} illustre la hi\'erarchie de rectangles englobants 
% 
% \begin{figure}[!h]
% \centering
% \includegraphics[width=0.4\textwidth]{./fig/p2pr-tree}
% % Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
% %\caption{Exemple d'arbre R en 2 dimensions (adapt\'e de \cite{coursenst})}
% \caption{Construction d'une instance de l'overlay P2PR-tree.}
% \label{fig:p2pr-tree}
% \end{figure}   
% La gestion des requ\^etes de plus proches voisins est propos\'ee par \cite{demirbas03peer}, dans le contexte de r\'eseaux de capteurs. 
% \cite{demirbas03peer} se diff\'erencie de P2PR-tree notamment dans la strat\'egie de placement des donn\'ees : l'arbre R est construit \`a partir d'une partition de
% l'ensemble des capteurs, et non de d'une partition de l'ensemble des donn\'ees en rectangles englobant les donn\'ees d\'etenues par un pair. 

\paragraph{Requ\^etes multidimensionnelles par intervalles et requ\^etes skyline}
% SSP \cite{wang07efficient} (<< Skyline Space Partitioning >>) est un algorithme de r\'esolution de requ\^etes skyline bas\'e sur BATON. 
% Wang \emph{et al.} conservent l'arbre binaire de la version originelle de BATON et lui adaptent 
% un espace des donn\'ees multidimensionnel en utilisant une courbe de remplissage Z. 
% L'espace des donn\'ees, de dimension $d$, est d\'ecoup\'e en r\'egions \`a l'aide d'hyperplans de dimensions $d-1$, en alternant les directions entre les dimensions. 
% Chaque r\'egion est identifi\'ee par une cl\'e, qui transcrit sa position relative aux hyperplans : 
% pour une cl\'e donn\'ee, le $i$-\`eme bit est \'egal \`a $1$ (resp. $0$) si la r\'egion associ\'ee est sup\'erieure (resp. inf\'erieure) pour la $i$-\`eme coordonn\'ee. 
% Les informations maintenue par un n\oe ud dans SSP sont de deux sortes : (i) des informations li\'ees \`a la r\'egion supervis\'ee ; (ii) 
% des informations de routage en tant que sommet dans un overlay BATON (cf. au-dessus pour un rappel). 
% Les informations sur la r\'egion sont : (a) sa cl\'e ;  (b) le tableau d'hyperplans contigus (<< split history >>), avec des entr\'ees de la forme $(SplitPos,SplitDim)$ o\`u 
% $SplitDim$ est une dimension et $SplitPos$ la coordonn\'ees du plan selon cette dimension ; 
% (c) l'intervalle de valeurs contenu dans la r\'egion. 
% %, (d) la dimension correspondant \`a la direction de l'hyperplan de la prochaine partition. 
% 
% Les cl\'es sont plac\'ees dans l'arbre BATON de telle mani\`ere \`a faire correspondre l'ordre total des r\'egions travers\'ees par la courbe de remplissage et 
% l'ordre total sur les r\'egions obtenu lors du parcours infixe de l'arbre BATON. 
% La figure \ref{fig:ssp} donne un exemple d'\'etat de n\oe ud dans une instance d'overlay SSP, en tant que section de la courbe (en haut) et en tant que sommet de l'arbre (en bas). 
% 
% % \begin{figure}[!h]
% % \centering
% % \includegraphics[width=0.4\textwidth]{./fig/isky}
% % % Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
% % %\caption{Exemple d'arbre R en 2 dimensions (adapt\'e de \cite{coursenst})}
% % \caption{Construction d'une instance de l'overlay iSky.}
% % \label{fig:isky}
% % \end{figure}  
% 
% \begin{figure}
% \centerline{\subfigure[Partition des donn\'ees et nommage des r\'egions]{\includegraphics[width=0.4\textwidth]{./fig/isky_haut}}
% 	    \hspace{1cm}
%  	    \subfigure[Placement des cl\'es sur BATON]{\includegraphics[width=0.4\textwidth]{./fig/isky_bas}}}
% \caption{Construction d'une instance de l'overlay SSP (via \cite{wang07efficient}).}
% \end{figure}
% 
% %Dans l'arbre qui en r\'esulte, le sous-arbre droit correpond aux r\'egions 
% %du << m\^eme >> c\^ot\'e de l'hyperplan par-rapport \`a la r\'egion associ\'ee au n\oe du courant, le sous-arbre gauche aux r\'egions de l'autre c\^ot\'e.
% 
% Sur r\'eception d'une requ\^ete exacte ou par intervalles, un n\oe ud commence par v\'erifier si l'objet recherch\'e est couvert par sa propre r\'egion. 
% Sinon, il consid\`ere parmi son historique 
% l'hyperplan orthogonal avec la direction minimisant la distance avec l'objet recherch\'e. Soit $j$ la position dans le tableau de cet hyperplan, 
% le n\oe ud courant choisit alors un voisin auquel transmettre la requ\^ete parmi ceux dont la cl\'e diff\`ere pour le $j$-\`eme bit (\`a (1,\ldots,j-1) premiers bits constants). 
% Soulignons l'analogie avec le routage par pr\'efixes (cf. routage Plaxton\cite{plaxton99accessing}). 
SSP (<< Skyline Space Partitioning >>) est un algorithme de r\'esolution de requ\^etes skyline propos\'e dans \cite{wang07efficient}, 
utilisant un overlay bas\'e sur BATON dont la description se trouve imm\'ediatement ci-dessus. 

Le principe de SSP est le suivant. L'espace des donn\'ees est d'abord \'elagu\'e, puis une recherche exhaustive est effectu\'ee dans le sous-espace de recherche restant. 
L'\'elagage s'op\`ere \`a partir du n\oe ud couvrant le point correspondant \`a l'\'el\'ement maximal (pour un probl\`eme de maximisation) de l'espace des attributs. 
Le front de Pareto local des donn\'ees
index\'ees par ce n\oe ud, nomm\'e $SQStarter$, est assur\'e d'appartenir au front de Pareto global. Le front de Pareto local \`a $SQStarter$ 
est calcul\'e et le point plac\'e aux coordonn\'ees de la donn\'ee maximale est appel\'e $p_{md}$. 
Il sert de r\'ef\'erence pour l'\'elagage : tous les points domin\'es par $p_{md}$ sont \'ecart\'es. L'espace de recherche circonscrit, correspondant \`a un ensemble 
d'hyper-rectangles parall\`eles aux $d$ dimensions et s'intersectant au niveau de $SQStarter$, est illustr\'e \`a la figure \ref{fig:skylineSSP} (en gris\'e). 
La recherche des n\oe uds Pareto-optimaux se poursuit ensuite, men\'ee en parall\`ele par chaque n\oe ud dont la r\'egion recouvre au moins partiellement les hyper-rectangles. 


\begin{figure}[!h]
\centering
\includegraphics[width=0.3\textwidth]{./fig/skylineSSP.png}
% Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
\caption{Sous-espace de recherche du front de Pareto (pour un probl\`eme de minimisation), \`a partir du point $p_{md}$, appartenant au n\oe ud $SQStarter$.}
\label{fig:skylineSSP}
\end{figure}  

\paragraph{}
Nous finissons cette section par la solution de r\'esolution de requ\^etes skyline qui pr\'esente le plus de familiarit\'e avec la notre. 
La solution DSL \cite{wu06parallelizing} est un protocole de r\'esolution parall\`ele et progressive de requ\^etes skyline
 \emph{sous contraintes}, au sein d'une architecture sans partage. Les objectifs et les conditions sont analogues aux notres. 
Comme PosNet, DSL exploite la notion d'ordre partiel pour structurer l'overlay P2P. 

Initialement, le r\'eseau est structur\'e en un overlay de type 
CAN, de m\^eme dimensionalit\'e que celle de l'espace des attributs.
L'espace des attributs est partitionn\'e en r\'egions (hypercubes) et chaque r\'egion est affect\'ee \`a un pair. 

\begin{figure}[!h]
\centering
\includegraphics[width=0.7\textwidth]{./fig/wu}
% Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
%\caption{Construction de l'instance d'overlay DSL (b) associ\'ee \`a la contrainte d'intervalles $((0.3,0.3)(0.9,0.9))$ sur l'espace des attributs (a), et propagation de la requ\^ete skyline dans cet overlay}
\caption{(a) Partition de l'espace des attributs sous la contrainte d'intervalles $((0.3,0.3)(0.9,0.9))$ et (b) instance d'overlay DSL inf\'er\'ee et propagation 
de la requ\^ete skyline dans cet overlay}

\label{fig:wu}
\end{figure} 

Soit une requ\^ete skyline associ\'ee \`a un ensemble de contraintes d'intervalles, les contraintes d\'elimitant un espace de recherche $H$ (un hypercube), 
DSL s\'electionne les n\oe uds dont la r\'egion supervis\'ee intersecte $H$ et les organise
 en un arbre de diffusion qui va permettre d'optimiser le traitement de la requ\^ete. \`A la racine de l'arbre se trouve 
le n\oe ud couvrant le plus petit \'el\'ement de $H$ (pour le probl\`eme de minimisation illustr\'e figure \ref{fig:wu}). 
Lors de la r\'esolution, la requ\^ete est propag\'ee le long de l'arbre et chaque n\oe ud travers\'e calcule le front de Pareto local. 
Les r\'esultats interm\'ediaires sont propag\'es en sens inverses, les donn\'ees domin\'ees \'elimin\'ees en chemin et les donn\'ees restantes agr\'eg\'ees \`a la racine. 

Le routage d'une requ\^ete de front de Pareto est optimis\'e en exploitant l'ordre de 
Pareto d\'efini sur l'ensemble de donn\'ees. 
Etant donn\'e cet ordre partiel sur les donn\'ees, et \'etant donn\'e un placement des donn\'ees dans DLS pr\'eservant la localit\'e, 
il existe une relation d'ordre partiel sur l'ensemble des r\'egions couvrant $H$, nomm\'ee \emph{Skyline Dependent} telle que : une r\'egion $r_d$ est << Skyline D\'ependent >>
d'une r\'egion $r_D$ s'il existe un point dans $r_d$ qui soit domin\'e par un point de $r_D$. 

En organisant les n\oe uds en un graphe orient\'e, les arcs exprimant la relation de d\'ependence entre les n\oe uds, on obtient un arbre de pr\'ec\'edence
 dans lequel une requ\^ete se propage d'abord dans les n\oe uds dominants avant d'atteindre les n\oe uds domin\'es. Il est alors 
possible pour un n\oe ud de retourner des solutions pertinentes sans avoir \`a attendre la propagation compl\`ete de la requ\^ete, voire d'\'elaguer l'arbre. En effet, si un n\oe ud dominant retourne une solution localement optimale, 
elle est forc\'ement optimale par-rapport \`a la solution localement optimale d'un n\oe ud qu'il domine (donc il n'est pas n\'ecessaire de propager la requ\^ete \`a celui-ci). 

L'arbre est construit dynamiquement \`a chaque requ\^ete, en fonction des contraintes d'intervalles, et au fur et \`a mesure que se propage la requ\^ete. 
La pr\'ec\'edence des n\oe uds est d\'etermin\'ee
gr\^ace aux propri\'et\'es topologiques de l'ordre de Pareto d\'efini sur l'espace ces attributs. Celui-ci est d\'ecoup\'e r\'ecursivement en utilisant le point le plus grand de la r\'egion du n\oe ud racine, en partitionnant $H$ \`a cet endroit parall\`ement aux axes, puis en r\'eit\'erant sur le sous-espace ainsi d\'efini des n\oe uds domin\'es jusqu\`a atteindre le dernier n\oe ud couvrant $H$. Le voisinage d'un n\oe ud est donc compos\'e des n\oe uds 
dont il est d\'ependent (et dont il doit attendre le r\'esultat du traitement de la requ\^ete avant de retourner les siens), et des n\oe uds qui d\'ependent de lui (et
qui sont en attente sur lui). Les connexions sont \'etablies dynamiquement lors de la partition de l'espace.


%  : l'espace des donn\'ees
% multidimensionnel est d\'ecompos\'e en r\'egions (hypercubes) et chaque r\'egion affect\'e \`a un pair. Chaque pair connait les pairs responsables d'une r\'egion contig\"ues \`a 
% la leur. 


%\subsubsection{Discussion}

% La comparaison entre BATON et \cite{liau04efficient} illustre les choix de conception des solutions bas\'es sur des arbres, 
% et les diff\'erents compromis sous-jacents. 
% Les deux solutions on en commun de distribuer un arbre sur un overlay (chaque pair supervisant un sommet), d'ajouter de
% l'information aux n\oe uds \`a des fins de routage et de supporter les requ\^etes unidimensionnelles par intervalles.
% Elles diff\`erent sur leur architecture : (i) sur la nature de l'arbre : \cite{liau04efficient} utilise un arbre quelconque ; 
% (ii) sur la composition exacte du voisinage : \cite{liau04efficient} n'utilise pas de liens adjacents et utilise un nombre fixe de liens transverses. 
% %(exactement un lien sur n\oe ud partageant le m\^eme p\`ere et un lien sur un n\oe ud de p\`ere distinct). 
% Les remarques qui peuvent \^etre faites sont que le choix d'un 
% arbre non \'equilibr\'e pour \cite{liau04efficient}, avec la possibilit\'e d'un arbre d\'eg\'en\'er\'e, ne permet pas de
% garantir les performances de recherche. De plus, l'absence de liens longs dans \cite{liau04efficient} 
% rallonge les routes par-rapport \`a BATON, tout en facilitant la maintenance de l'overlay.  
% Enfin, la flexibilit\'e au niveau du nombre de fils, pour \cite{liau04efficient}, ou de liens transverses, pour BATON, permet 
% d'affiner le compromis entre co\^ut de maintenance et co\^ut de recherche.

\paragraph{} Afin de compl\'eter la pr\'esentation des possibilit\'es offertes par l'utilisation d'arbres dans les index P2P, nous mentionnons sans nous y attarder 
l'existence de solutions hybrides, cherchant \`a r\'eunir les avantages des arbres et ceux des
 overlays bas\'es DHT. Parmi les combinaisons explor\'ees, citons : 
arbre quaternaire sur Chord \cite{tanin07using} ou sur CAN \cite{zuo08can-qtree} ; 
arbre k-d\footnote{L'arbre k-d repose sur le m\^eme principe que l'arbre quaternaire sauf que l'espace est divis\'e en deux sous-r\'egions et non plus quatre.} 
sur CAN avec Murk \cite{ganesan04one}, 
sur Chord avec \cite{gao07efficient} ou sur un graphe \`a enjambements avec \cite{zhang04skipindex} ; 
arbre B+\footnote{L'arbre B+ diff\`ere l\'eg\`erement de l'arbre B, en ceci que toutes les donn\'ees sont stock\'ees exclusivement dans des feuilles.} 
sur Chord avec P-Tree \cite{crainiceanu04querying}.

\section{R\'esum\'e et discussion}

Nous avons pass\'e en revue diff\'erentes approches pour la recherche de donn\'ees dans les syst\`eme distribu\'es. Apr\`es 
avoir \'etabli une grille d'\'evaluation pour les m\'ethodes d'acc\`es : d\'ecentralisation compl\`ete, 
support natif et progressif des requ\^etes multidimensionnelles par intervalles et skyline ainsi que compl\'etude de recherches,  
l'\'etude s'est focalis\'ee sur les solutions d'index P2P structur\'ees. Nous en faisons ici une br\^eve synth\`ese pour les solutions dirig\'ees par le routage et discutons plus en d\'etail des solutions bas\'ees sur des arbres.  

\paragraph{}
%Une synth\`ese de l'\'etat de l'art dans le domaine s'\'enonce comme suit. 
La recherche sur les index P2P commence avec l'introduction des tables de hachages distribu\'ees ou DHT 
avec entre autres \cite{stoica01chord, ratnasamy01scalable, rowstron01pastry, maymounkov02kademlia}, 
mais est rapidement \'etendue \`a des requ\^etes
plus complexes telles que l'indexation multidimensionnelle, par exemple \cite{bharambe04mercury, huebsch03querying}, 
les requ\^etes de similarit\'e \cite{tang02psearch, gupta03approximate}, les requ\^etes unidimensionnelles 
par intervalles \cite{aspnes03skipgraph, crainiceanu04querying, jagadish05baton} ou sur plusieurs 
dimensions \cite{ganesan04one, chawathe05case, shu05supporting, jagadish06vbi-tree, beaumont07voronet} 
et enfin les requ\^etes skyline \cite{wu06parallelizing, chen08isky, wang08intelligent}. 

Les DHT peuvent \^etre \'etendues aux requ\^etes par intervalles en employant une fonction de hachage pr\'eservant la localit\'e, comme dans \cite{aberer03p-grid, cai04maan}, ou bien 
aux requ\^etes multidimensionnelles en lin\'earisant l'espace des donn\'ees, gr\^ace \`a l'application d'une courbe remplissante par exemple \cite{andrzejak02scalable, ganesan04one}.  
Toutefois les performances de recherches des solutions bas\'ees DHT sont affect\'ees par l'impossibilit\'e de reconstituer totalement les propri\'et\'es de 
localit\'e spatiale des donn\'ees dans un espace multidimensionnel en utilisant une strat\'egie de placement des donn\'ees par partition d'un espace de cl\'es. 

D'autres propositions reposent sur des variantes robustes et distribu\'ees des listes \`a enjambements \cite{harvey03skipnet, aspnes03skipgraph}. 
Ces propositions ont en commun avec les solutions bas\'ees sur une tesselation de Vorono\"i \cite{beaumont07voronet} 
d'\^etre pr\'esent\'ees en tant que \emph{structures de donn\'ees distribu\'ees}. En d'autres termes, les calculs de complexit\'e
sont exprim\'es en fonction du nombre $n$ de donn\'ees index\'ees dans le r\'eseau et non du nombre $N$ de pairs, ce qui devient probl\'ematique quand $N >> n$. 
De m\^eme les protocoles sont incomplets et d\'ecrits relativement aux donn\'ees et non aux n\oe uds les indexant.  

Enfin, une approche consiste \`a porter sur un overlay P2P des structures de donn\'ees de type arbre \cite{liau04efficient, jagadish05baton, jagadish06speeding, jagadish06vbi-tree}. 
Un obstacle cl\'e \`a surmonter est la gestion du point de centralit\'e que constitue la racine. 
Typiquement, les n\oe uds internes proches de la racine sont sollicit\'es plus fr\'equemment lors du routage des requ\^etes, formant des goulots d'\'etranglement. 
D'o\`u la mise-en-place de strat\'egies par les solutions pr\'esent\'ees ci-dessus, visant \`a r\'etablir la sym\'etrie du r\'eseau en assurant une charge \'egale sur l'ensemble des n\oe uds.  
Ces strat\'egies impliquent toutes d'inf\'erer \`a partir d'un arbre un graphe de routage 
cr\'eant des << raccourcis >> dans l'arbre. Que ce soit par le biais de liens transverses ou bien de liens suivant un ordre donn\'e sur les n\oe uds, l'objectif 
est de cr\'eer un chemin entre toute paire de n\oe ud, qui soit le plus court possible. 

% Une approche unifi\'ee de la comparaison et de l'\'evaluation des solutions d'index P2P reposerait sur l'\'etude des propri\'et\'es de graphes des diff\'erentes topologies 
% d'overlay, avec pour m\'etrique entre autres : le diam\`etre, la distance moyenne, le degr\'e des n\oe uds, etc. TODO on peut se demander d ailleurs pourquoi je ne fais pas une \'etude 
% des solutions d index P2P bas\'ee sur les propri\'et\'es math\'ematiques des g\'eom\'etries d'overlay, non ? Tiens c est une id�e, je vais refaire cet etat de l art\ldots 

\paragraph{}La gestion d\'ecentralis\'ee de requ\^etes skyline, qui fait partie de nos principales contributions, reste peu investigu\'ee.   
 La derni\`ere partie de ce chapitre d\'ecrit deux solutions int\'eressantes. De mani\`ere g\'en\'erale, les solutions existantes ne 
satisfont pas les crit\`eres que nous avons \'edict\'es. 

Concernant le crit\`ere de compl\'etude, SSP n'offre que des garanties probabilistes (malgr\'e la revendication du contraire). 
En effet, les premi\`eres \'etapes d'\'elagage de l'espace de recherche reposent 
sur des hypoth\`eses restrictives concernant la distribution des donn\'ees, avec notamment l'hypot\`ese d'existence et d'unicit\'e de $p_{md}$. 
Le placement des donn\'ees dans SSP reposant sur une partition de l'espace des attributs, rien ne garantit que la r\'egion couverte par $SQStarter$ contienne effectivement des donn\'ees.
Le cas o\`u $SQStarter$, ou les SR d\'eriv\'es, ne poss\`ederaient pas de donn\'ees n'est pas explicit\'e. Par-ailleurs, 
\`a supposer que $SQStarter$ n'est pas vide, SSP suppose qu'il poss\'ede un plus grand (toujours pour un probl\`eme de maximisation)
 \'el\'ement $p_{md}$ : le cas o\`u il ne poss\`ederait que des \'el\'ements 
maximaux n'est pas consid\'er\'e. En admettant que l'on d\'esigne un \'el\'ement maximal arbitraire en guise de $p_{md}$, les rectangles de recherches ne couvrent plus
l'int\'egralit\'e des r\'egions pouvant intersecter le front de Pareto. 
D'autres solutions encore, comme \cite{hose06processing} aussi bas\'ees sur des arbres distribu\'es, choisissent d'approximer le front de Pareto.   

Une autre limitation concerne le crit\`ere de prise de d\'ecision d\'ecentralis\'ee. 
%prise de d\'ecision sans connaissances globales, dont l'acquisition et la maintenance est difficilement 
%compatible avec un contexte P2P. 
Ainsi l'approche de iSky\cite{chen08isky}, aussi bas\'ee sur BATON et non d\'etaill\'ee ici, impose notamment que chaque pair maintienne 
une information globale \`a jour (concernant l'identit\'e des n\oe uds appartenant \`a l'espace de recherche du front de Pareto, les << initial skyline peers >>), 
ce qui est difficilement compatible avec un contexte P2P. 
Quant \`a SKYPEER \cite{vlachou07skypeer}, il utilise une infrastructure de super-pairs pour calculer des fronts de Pareto locaux, qui sont 
ensuite centralis\'es au niveau d'un super-pair pour \^etre agr\'eg\'es en un front de Pareto global. 
Si une partie des calculs est distribu\'ee, la prise de d\'ecision est, elle, centralis\'ee.  

La solution satisfaisant le mieux nos crit\`eres est DSL. Exploitant un ordre partiel d\'efini sur l'ensemble des donn\'ees, DSL \'elague efficacement 
l'espace de recherche de telle sorte \`a ce qu'il soit minimal et suffisant, tout en \'etant progressif et totalement d\'ecentralis\'e. 
Ce qui distingue l'approche de DSL et celle de PosNet est le placement des donn\'ees. DSL op\`ere une partition de l'espace des attributs tandis que 
PosNet op\`ere une partition de l'ensemble des donn\'ees. Cela a une incidence sur le graphe des pairs, puisque l'ordre d\'efini sur les donn\'ees se traduit 
directement en un ordre partiel sur les parties et donc en propri\'et\'es topologiques de l'espace, qu'exploite DSL pour la construction dynamique de ses overlays. 
La topologie de DSL n'est modifi\'ee que par l'arriv\'ee ou le d\'epart d'un pair. 
Par-ailleurs, le graphe des pairs DSL refl\^ete une relation de pr\'ec\'edence dans la r\'esolution de la requ\^ete, et non l'ordre partiel directement comme le cas de PosNet. 
Le principe du routage en est donc totalement diff\'erent. Soulignons \`a ce propos que 
DSL est d\'edi\'e aux requ\^etes skyline sous contraintes, tandis que nous visons avec PosNet un framework de r\'esolution de requ\^etes.
Enfin, DSL impose pour chaque requ\^ete la construction d'un overlay structur\'e selon la relation d'ordre, avant d'entamer la proc\'edure de localisation. 
En fonction de la taille de l'espace de recherche d\'efini par les contraintes, cette \'etape peut devenir probl\'ematique. 
Si l'on observe que toute la complexit\'e de ces solutions
 r\'eside dans la construction et la maintenance d\'ecentralis\'ees de la structure d'ordre partiel. 
Tandis que DSL g\`ere cette complexit\'e \`a la vol\'ee pour chaque requ\^ete, PosNet maintient l'ordre en
 distribuant la complexit\'e dans le temps, au fur et \`a mesure de l'\'evolution de l'overlay (ajout de n\oe uds, insertion de donn\'ees, \ldots).  


% La solution d'index offrant le plus de ressemblance avec PosNet pour la gestion des requ\^etes skyline est sans doute \cite{wu06parallelizing}. 
% [\ldots] EST CE QUE support skyline plus general ? range ? 

Cet \'etat de l'art fournit les pr\'emisses de notre proposition d'index P2P s\'emantique, PosNet, que nous pr\'esentons dans le chapitre suivant. 

% 
% L'arbre binaire de recherche de BATON utilise des liens transverses entre n\oe uds de m\^eme profondeur pour permettre
% aux requ\^etes d'\^etre transmises  
%%\footnote{On d\'efini un routage glouton de la mani\`ere suivante : Dans un graphe $(V,E)$ muni d'une fonction de distance 
%%$\delta : V \times V \rightarrow \mathcal{\mathbb{R}}^+$
%%, on parle de routage \textbf{glouton} lorsqu'\'etant donn\'e un n\oe ud INSERER FORMULE}
%%
%%%$\delta : V \times V \rightarrow \mathcal{\mathbb{R}}^+$, on parle de routage \textbf{glouton} lorsqu'\'etant donn\'e un n\oe ud INSERER FORMULE }
%%%cible $c$, un n\oe ud $u$ dot\'e d'un voisinage $V(u)$ transmet une requ\^ete au voisin $v \in V(u) \text{ tel que } \delta (v,c)=\min_{x \in V(u)} \delta (x,c)$}
%%%$v \in V (u) \text{ tel que } \delta (v, c)=\min_{x \in V (u)} \delta (x, c)$. }
%%\footnote{Naor \emph{\emph{\emph{et al.}}} proposent une optimisation du routage glouton (appel\'e \textit{ neighbor of neighbor
%% greedy }) pour les index bas\'es DHT. Leur algorithme peut \^etre impl\'ement\'e comme une sur-couche au-dessus du routage glouton et permet
%% d'atteindre une longueur des routes optimale (nombre de sauts en O(log $n$/
%% log log $n$)) tout en pr\'eservant les bonnes propri\'et\'es du routage
%% glouton (simplicit\'e, tol\'erance aux pannes et localit\'e dans l'espace de
%% nommage). Ces travaux sont en-dehors de notre champ d'\'etude. Il est donc
%% laiss\'e au lecteur int\'eress\'e le soin de se r\'ef\'erer \`a [  Know Thy
%% Neighbor's Neighbor : Better Routing for Skip Graphs and Small Worlds  ]. }
%%
%%,minimisant la distance s\'eparant le n\oe ud courant de la destination (entre
%%$f$ et $u_i$.). L\`a o\`u les solutions diff\`erent, c'est dans la
%%d\'efinition de la distance. Cette distance d\'epend du graphe/topologie
%%logique/g\'eom\'etrie des pairs sous-jacent (ou pour employer les termes de
%%Gummadi \emph{\emph{\emph{et al.}}}, la  g\'eom\'etrie de routage   ou \textit{routing geometry
%%}[Gummadi   The Impact of DHT Routing Geometries on Resilience and Proximity 
%%]).
%%
%%\paragraph{Propri\'et\'es}
%%Performances prouv\'ees : degr\'e,
%%diam\`etre, insertion, engorgement. [pour une formalisation du fonctionnement
%% d'un overlay bas\'e DHT, cf. {\cite{D2B}}]. 
%%% >> >> >> >> >> >> >> >> >> >> >> >>> [A CONSERVER ?] Les autres
%%% propri\'et\'es communes sont :
%%% \begin{itemize}
%%%   \item  Les n\oe uds et les liens peuvent conna\^{\i}tre des pannes. Quand
%%%   c'est le cas, le r\'eseau doit pouvoir continuer \`a fonctionner, m\^eme en
%%%   mode d\'egrad\'e. La connectivit\'e d'un r\'eseau mesure sa r\'esilience,
%%%   c'est-\`a-dire sa capacit\'e \`a fonctionner en cas de d\'efaillance
%%%   partielle du syst\`eme. Elle se mesure par le nombre minimum de n\oe uds ou de
%%%   liens qui doivent tomber en panne simultan\'ement pour que le r\'eseau soit
%%%   partitionn\'e en deux ou plus r\'eseaux disjoints. Plus la connectivit\'e
%%%   d'une r\'eseau est grande, plus celui-ci est robuste.
%%%   
%%%   \item \textit{} Ceci est une m\'etrique de congestion dans un r\'eseau.
%%%   Elle est calcul\'e de la mani\`ere suivante : Soit une bi-partition du
%%%   r\'eseau en deux ensembles de n\oe uds $A$ et $B$ ; soient la cardinalit\'e
%%%   des ensembles $Na$ et $Nb$, avec $Nb \leq Na$ ; soit $I$ le nombre de liens
%%%   entre $A$ et $B$ ; alors l'\'etroitesse du r\'eseau est \'egale \`a la
%%%   valeur maximale de $Nb / I$ pour toutes les partitions du r\'eseau. Plus $Nb
%%%   / I$ est \'elev\'e, plus la congestion entre les n\oe uds de $B$ et les n\oe uds
%%%   de $A$ risque d'\^etre \'elev\'ee.
%%
%%% La sous-section suivante pr\'esentent les solutions bas\'ees DHT
%%% fondamentales. Le choix de la structure de graphe contraignant l'ensemble des
%%% \'etapes de conception d'un r\'eseau overlay, le choix a \'et\'e de comparer
%%% l'existant sur la base de cette structure. 
%%
%%%[Solutions pr\'esent\'ees fonctionnellement \'equivalentes => on choisi de les discriminer en fonction de leur g\'eom\'etrie]
%%
%%\subsubsection{G\'eom\'etrie d'index bas\'es DHT}
%%Fonctionnalit\'es DHT : utilisation de fonction de hachage pour distribuer donn\'ees sur pairs + routage glouton dans graphe des pairs. 
%%Plusieurs graphes+algos de routage ont \'et\'e propos\'es :  
%
%%Les g\'eom\'etries d'index bas\'es DHT sont dans leur majorit\'e adapt\'es des
%%graphes d'interconnexion utilis\'es en architectures parall\`eles, qui ont
%%\'et\'e largement \'etudi\'es depuis les ann\'ees 80 [ouvrage??? de Tom
%%Leighton, 1992] : hypercubes, tores, arbres, graphes de Bruijn, r\'eseaux
%%papillon\ldots Il est int\'eressant de noter que [Gurmeet Singh Manku   Routing
%%networks for distributed hash tables, 2003] g\'en\'eralise l'approche en
%%d\'emontrant que n'importe quelle topologie de routage parall\`ele peut \^etre
%%r\'eutilis\'ee pour le routage DHT. Nous nous contentons toutefois de
%%pr\'esenter dans ce qui suit les topologies les plus commun\'ement
%%\'evoqu\'ees.
%%
%%[SHEMA  /anneli/thesis/binder/StructuresGraphe.ppt]
%
%%Ces topologies de graphes ont pour point commun de permettre un routage des
%%requ\^etes sur la base de tr\`es peu d'information (tr\`es faible degr\'e des
%%n\oe uds) Par exemple, il suffit que les n\oe uds de Chord ait la connaissance
%%d'un seul voisin, pour qu'une donn\'ee, si elle est index\'ee, soit
%%localis\'ee et ce, quelque soit le nombre de n\oe uds dans le syst\`eme (la
%%taille du r\'eseau). Toutefois, en pire cas la requ\^ete est trait\'ee par
%%tous les n\oe uds. Afin d'\'eviter une recherche exhaustive, une optimisation
%%tr\`es courante consiste \`a ajouter des liens dans le graphe. Le principe de
%%ces liens est de cr\'eer des raccourcis dans le r\'eseau overlay. Chaque
%%n\oe ud connait alors non seulement ses voisins imm\'ediats mais aussi un ou
%%plusieurs n\oe uds \'eloign\'es. Le choix de ces voisins \'eloign\'es proc\`ede
%%d'un compromis : il faut \`a la fois parvenir \`a un diam\`etre logarithmique
%%et pr\'eserver le passage \`a l'\'echelle de la solution en limitant leur
%%nombre. Nous verrons le cas \'ech\'eant les strat\'egies mises en oeuvre.
%%Cette optimisation permet de garantir un faible diam\`etre (longueur maximale
%%entre deux n\oe uds, c'est-\`a-dire le nombre maximum de liens \`a traverser
%%pour envoyer une requ\^ete \`a un n\oe ud quelconque). Plus faible est le
%%diam\`etre, plus court est le d\'elai n\'ecessaire pour envoyer une requ\^ete
%%d'un n\oe ud source \`a un n\oe ud destination. De mani\`ere g\'en\'erale, les
%%r\'eseaux overlay structur\'es cherchent \`a pr\'esenter un diam\`etre
%%logarithmique (routage en $O ( \text{ log } n)$ sauts dans le r\'eseau overlay,
%%pour un r\'eseau de taille $n$ n\oe uds) et des tables de routage compactes
%%(nombre de voisins en $O ( \text{ log } n)$ 
%%- [Viceroy] parvenant m\^eme \`a
%%$(O (1))$). Typiquement, les tables de routage sont ou bien de taille
%%constante, ou bien de taille logarithmique.
%
%%On peut donc voir les topologies de DHT comme la superposition i) d'une
%%topologie "de base", assurant la \textit{reachability }des donn\'ees et
%%donc la \textit{correctness }des algorithmes de routage ; et ii) d'une
%%topologie de liens longs  MAL DIT], assurant \`a la solution un diam\`etre
%%logarithmique et donc un routage en $Olog$.
%
%%Pour une \'evaluation des impl\'ementations de DHT disponibles, se reporter \`a [kato07evaluating]. 
%
%%Dans ce qui suit : $n$ d\'esigne le nombre de n\oe uds. Pour des raisons de
%%lisibilit\'e, on suppose que les identifiants sont cod\'es sur log $n$ bits
%%(en g\'en\'eral, les algorithmes choisissent $N \gg n$ , de telle sorte \`a ce
%%que l'espace de nommage ne soit pas totalement peupl\'e). Par ailleurs, la
%%longueur d'une route (ou distance de routage) est d\'efinie comme le nombre de
%%liens travers\'es sur une route.
%
%%\paragraph{Uni-dimensionnel% -> Chord, Symphony / Pastry, Tapestry, Oceanstore / Viceroy / Koorde 
%%}
%% >> >> >> >> >> >> >> >> >> >> >> cf. resume_dht.pdf
%
%
%
%
%\paragraph{Multi-dimensionnel% : CAN, INS/Twine
%}
%% CAN \cite{ratnasamy01content} utilise un tore de dimension $d$ r\'eparti entre les n\oe uds. L'espace de
%% nommage est l'espace Cart\'esien de dimension $d$, partitionn\'e en
%% hyper-rectangles. Chaque hyper-rectangle, appel\'e \textit{zone, }est
%% ensuite affect\'e \`a un n\oe ud (on identifie un n\oe ud \`a sa zone).
%% L'identifiant d'un n\oe ud repr\'esente sa position dans cet espace. Dans la
%% solution originale originale, $d$ est fix\'e arbitrairement (et notamment
%% $d$<log $n$). Mais pour faciliter la comparaison avec les autres solutions, on
%% prend ici $d =$log $n$ et on raisonne sur un tore de dimension log $n$.
%% La distance entre deux n\oe uds est \'egale \`a la distance euclidienne entre
%% leurs coordonn\'ees. Chaque n\oe ud maintient une table de routage compos\'ee
%% des n\oe uds partageant un plan de $d - 1$ dimensions (=> 2*log $n$ voisins).
%% Lorsqu'il re\c{c}oit une requ\^ete, un n\oe ud la transmet au n\oe ud parmi ses
%% voisins le plus proche du n\oe ud cible, dans l'espace des coordonn\'ees. La
%% route emprunt\'ee par une requ\^ete lors du processus de recherche approxime
%% par cons\'equent la ligne droite entre le n\oe ud d'entr\'ee de la requ\^ete et
%% le n\oe ud cible, dans l'espace des coordonn\'ees.
%% [Pour des ex. d'applications construites par-dessus ces overlays, cf. Related
%% Work dans {\cite{Tapestry}}]
%
%Un autre exemple d'index multidimensionnel se trouve \`a l'Institut de technologie du Massachusetts MIT, en l'objet d'INS (\emph{Intentional Naming Service}). 
%Le syst\`eme de d\'ecouverte de service et de localisation de ressources INS \cite{adjie-winoto99design}) promeut un mod\`ele d\'eclaratif qui permet \`a un utilisateur de  
%d\'esigner la ressource recherch\'ee de mani\`ere "intentionnelle" plut\^ot que par un identifiant. Ainsi un exemple de requ\^ete serait : "une imprimante noir et blanc 
%recto-verso du 5\`eme \'etage" plut\^ot que $printxxx.poleia.lip6.fr:lp0$. 
%Ce mod\`ele orient\'e service avantage l'utilisabilit\'e et la robustesse, gr\^ace au d\'ecouplage entre fonctionnalit\'es et ressources physiques sous-jacentes.  
%Pour am\'eliorer le passage \`a l'\'echelle d'INS, l'extension INS/Twine \cite{balazinska02ins} se fonde sur un overlay P2P bas\'e DHT. 
%Son originalit\'e repose sur le support d'un mod\`ele de donn\'ees semi-structur\'e pour les ressources, 
%type description XML. A cette fin, la hi\'erarchie des paires attribut-valeur d'une ressource est transform\'ee en structure arborescente, d\'ecomposable en sous-arbres lin\'eaires 
%appel\'es "brindilles" \emph{strands}. Une ressource satisfait une requ\^ete si l'arbre repr\'esentant la requ\^ete est une brindille de l'arbre de la ressource, 
%ce qui permet \`a INS/Twine de g\'erer non seulement les requ\^etes exactes mais aussi les requ\^etes partielles.
%%INS/Twine g\'ere donc non pas des paires attribut-valeur individuellement, mais des listes de paires. 
%Etant donn\'ee la strat\'egie de routage bas\'ee DHT, la strat\'egie de 
%placement des auteurs est de faire correspondre \`a chaque brindille d'une ressource une cl\'e num\'erique, par le biais d'une fonction de hachage. 
%
%\paragraph{Tableau r\'ecapitulatif et discussion}
%[A INSERER : tableau comparatif des perfs, cf. {\cite{naor07novel}},
%{\cite{www.irisa.fr/GDS/meetings/Slides/meeting9-2005-07-06/ACIGDS_06072005.pdf}}
%+ risson\_semantic\_index\_survey.pdf]
%
%Pour les avantages/d\'esavantages hachage, reprendre \cite{keleher02virtualized}
%
%Les index sans s\'emantique se caract\'erise par une indexation par cl\'es de
%hachage   classique  . Comme vu \`a la sous-section pr\'ec\'edente, les
%avantages sont nombreux mais deux types de limitation motivent le
%d\'eveloppement de solutions alternatives.
%
%En premier lieu, on a vu que l'utilisation d'une fonction de hachage permet
%une distribution uniforme al\'eatoire des donn\'ees sur les pairs. L'avantage
%imm\'ediat est une r\'epartition automatique de la charge dans le r\'eseau (en
%terme de nombre de n\oe uds g\'er\'es par chaque pair). La contrepartie en est
%la destruction de la proximit\'e s\'emantique : les donn\'ees proches
%s\'emantiquement ne sont pas situ\'ees \`a proximit\'e dans le r\'eseau. Cette
%dispersion rend difficile le traitement efficace des requ\^etes par plages de
%valeurs ou comparatives.
%
%En second lieu, l'espace de nommage dans le cas du hachage est   plat  .
%Ainsi, les ressources multidimensionnelles sont difficilement captur\'ees par
%des valeurs de hachage >> >> >> >> >> >> >>>COMMENTAIRE Les donn\'ees MD ont cela de
%complexes qu'elles n'admettent pas d'ordre total qui pr\'eserve la localit\'e.
%En d'autres termes, il n'y a pas de correspondance entre un espace de
%dimensionalit\'e sup\'erieure ou \'egale \`a 2 et un espace unidimensionnel,
%tel que deux objets proches dans le premier, le soit aussi dans le second
%{\cite{gaede98multidimensional}} << << << << << << << << <<  . Une approche naturelle
%pour la gestion de requ\^etes multidimensionnelles, est leur d\'ecomposition
%en requ\^etes unidimensionnelles, suivi du calcul de l'union des solutions sur
%une dimension retourn\'ees. A nouveau, cette approche est peu efficace [entre
%autres parce que l'ex\'ecution ind\'ependante des requ\^etes ne permet pas
%d'exploiter la s\'electivit\'e d'un attribut]. De mani\`ere g\'en\'erale, il
%n'existe pas de mani\`ere simple et \'evidente d'exploiter un\textit{}index
%unidimensionnel (\textit{single key structure}) pour la gestion de DMD.
%
%Ainsi les index sans s\'emantique, munis des fonctionnalit\'es de base des
%DHT, ne sont destin\'es qu'\`a des recherches par mot-cl\'e (\textit{lookup
%queries}/KBR). C'est peut-\^etre suffisant pour trouver un fichier ou pour
%r\'esoudre un nom de domaine. Mais nombre d'applications ne se suffisent pas
%de requ\^etes exactes et n\'ecessitent davantage de flexibilit\'e. L'objet des
%index s\'emantiques est de palier cette expressivit\'e limit\'ee.
%
%Contrairement aux index sans s\'emantique, les index s\'emantiques capturent
%les propri\'et\'es des objets, ainsi que les relations s\'emantiques entre ces
%objets. [on peut consid\'erer que les DHT regroupe/\textit{cluster} les
%donn\'ees selon leur index, tandis que les index avec s\'emantique regroupe
%les donn\'ees selon leur s\'emantique] Pour \'eviter le hachage   classique  
%des identifiants, deux approches principalement :
%
%La premi\`ere, consiste \`a \'etendre les solutions bas\'ees DHT existantes,
%en substituant au hachage classique une strat\'egie de placement pr\'eservant la localit\'e.
%La seconde, consiste \`a d\'evelopper des solutions non bas\'ees DHT.
%
%Les sous-sections suivantes pr\'esentent en d\'etails ces deux approches.
%
%\subsection{Requ\^etes par intervalles% -> ZNet, Squid, Murk, Scrap, / BATON / Raynet / SONAR
%}
%%Le support de requ\^etes par intervalles ou plages de valeurs dans les r\'eseaux P2P a \'et'e identifi\'e comme un probl\`eme de recherche 
%ouvert d'importance par Huebsch \emph{\emph{\emph{et al.}}} \cite{huebsch06querying}. 
%Les requ\^etes par intervalles sont intimement li\'ees \`a la notion de localit\'e des donn\'ees, c'est-\`a-dire de proximit\'e de ces donn\'ees dans l'espace d'origine. 
%%D\'ej\`a dans les syst\`emes traditionnels de bases de donn\'ees, le partitionnement par intervalles des tables dans le but d'optimiser les performances des requ\^etes est un probl\`eme bien connu. 
%Or comme vu pr\'ec\'edemment \ref{}, la principale propri\'et\'e m\^eme des DHT, qui est de permettre la r\'epartition de la charge, contrevient \`a cette notion de localit\'e, les rendant
%impropres \`a la r\'esolution efficace de requ\^etes par intervalles.
%% En effet, l'utilisation de fonctions de hachage dispersant al\'eatoirement les donn\'ees sur les n\oe uds conduit \`a la perte de l'information de localit\'e. 
%C'est bien l'efficacit\'e qui ici est en cause : une approche bas\'es DHT na\"ive de r\'esolution d'une requ\^ete par intervalle serait en effet 
%de d\'ecomposer la requ\^ete d'origine en autant de requ\^etes exactes que de points contenus dans l'intervalle, ce qui \`a l'\'evidence n'est pas envisageable. Une autre 
%possibilit\'e serait de hacher des intervalles, mais cela requ\'ererait une partition \emph{\emph{a priori}}. 
%
%Les efforts d\'eploy\'es pour impl\'ementer les requ\^etes par intervalles dans les r\'eseaux overlay P2P peuvent \^etre class\'es en ceux qui reposent leur strat\'egie de
%routage sur une DHT et et les autres, qui s'\'emancipent totalement de l'approche DHT. Les premiers achoppent sur
%l'efficacit\'e du traitement des requ\^etes, les seconds sur la r\'epartition de la charge, ces deux objectifs \'etant contradictoires.
%
%\subsubsection{Approche bas\'ee DHT}
%%Une strat\'egie de partitionnement distribue l'espace des solutions $S$ sur l'ensemble des n\oe uds $N$ et supporte l'ajout ou la suppression de solutions de $S$, ainsi que l'arriv\'ee ou le d\'epart de n\oe uds dans $N$. Une fois la strat\'egie de partitionnement choisie et les solutions distribu\'ees sur les n\oe uds, il reste \`a d\'ecider d'une strat\'egie de routage, afin de permettre la transmission des requ\^etes aux n\oe uds h\'ebergeant les solutions les satisfaisant.
%Dans une approche bas\'ee DHT, la strat\'egie de routage est de reprendre une g\'eom\'etrie d'overlay bas\'e DHT, 
%typiquement un anneau de type Chord \cite{stoica01chord} comme c'est le cas dans les solutions d\'etaill\'ees ci-apr\`es, et de substituer la strat\'egie de placement
%par hachage par une strat\'egie pr\'eservant la localit\'e des donn\'ees. A notre connaissance, ces strat\'egies rejoignent le plus souvent les m\'ethodes
%d'indexation spatiale de points (\emph{Point Access Methods} ou PAM), telles que d\'ecrites par Gaede \emph{\emph{\emph{et al.}}} \cite{gaede98multidimensional}. 
%Globalement, les approches propos\'ees se rangent selon trois classes (pour une exception, cf. \cite{agrawal07attribute}) :   
%\begin{enumerate}
%%\item Le non-utilisation de fonction de hachage \footnote{M\^eme sans le recours au hachage, la solution d\'ecrite s'apparente \`a une approche bas\'ee DHT : g\'eom\'etrie en anneau des n\oe uds, utilisation de liens longs pour le  routage au sein des \emph{hubs} (comme dans Symphony\cite{manku03symphony}), \ldots }
%\item L'utilisation de fonctions de hachage pr\'eservant la localit\'e ;
%\item La r\'eduction de la dimensionnalit\'e de l'espace des solutions ;
%\item TODO mal dit / L'utilisation d'une structure de donn\'ees hi\'erarchique (typiquement arborescente) et sa projection sur l'espace des cl\'es
%de mani\`ere \`a conserver (du moins en partie) les propri\'et\'es de localit\'e de la struture d'origine. 
%\end{enumerate}
%% Dans les deux cas, une fois la transformation effectu\'ee, la strat\'egie de partionnement r\'ealise une partition de l'espace unidimensionnel obtenu
%% en intervalles de valeurs cons\'ecutives, puis affecte chaque intervalle \`a un pair. 
%Les exemples suivants d\'etaillent la mise-en-\oe uvre de chacune de ces trois strat\'egies. 
%
%\paragraph{Utilisation de fonctions de hachage pr\'eservant la localit\'e : exemple de MAAN} \label{empilement}
%% \label {maan} MAAN \cite{cai04maan} r\'e-utilise la strat\'egie de routage de Chord \ref{chord}, en lui substituant dans la strat\'egie de placement une fonction de hachage pr\'eservant la localit\'e (\emph{Locality Preserving Hashing} ou LPH) \`a la fonction de hachage standard (typiquement SHA-1). Seul sont hach\'ees les attributs num\'eriques (les identifiants des n\oe uds et des attributs 
%% de type cha\^ines de caract\`eres ne sont pas concern\'es). 
%% Si les applications divergent selon l'acceptation du terme "localit\'e", les auteurs de MAAN en donne la d\'efinition suivante \cite{cai04maan} : 
%% La fonction de hachage $h$ est une fonction de hachage pr\'eservant la localit\'e si elle v\'erifie les 
%% propri\'et\'es suivantes : $h(v_i)<h(v_j)$ ssi $v_i<v_j$ et si un intervalle $[v_i,v_j]$ est d\'ecoup\'e en $[v_i,v_k]$ et $[v_k,v_j]$, 
%% alors l'intervalle correspondant $[h(v_i),h(v_j)]$ doit \^etre partag\'e en $[h(v_i),h(v_k)]$ et $[h(v_k),h(v_j)]$. 
%% % Wikepedia : locality preserving hashing is a hash function f that maps a point or points in a multidimensional coordinate space to a scalar value, 
%% % such that if we have three points A, B and C such that
%% % 
%% %     |A-B| < |B-C| \Rightarrow |f(A) - f(B)| < |f(B) - f(C)|. \,
%% % 
%% % In other words, these are hash functions where the relative distance between the input values is preserved in the relative distance between 
%% % of the output hash values; input values that are closer to each other will produce output hash values that are closer to each other.
%% 
%% %  [Triantafillou, Towards a unifying framework for complex query processing over structured peer-to-peer data networks]  hachage\textit{Locality Preserving Hashing} 
%% % ou LPH comme une fonction $h$ 
%% % monotone (i.e. $a < b \Rightarrow h (a) < h (b)$, tel que $h$ distribue uniform\'ement les donn\'ees appartenant \`a l'intervalle $[a, b] 
%% % \rightarrow [h (a), h (b)]$). 
%% Par ailleurs les auteurs s'attachent \`a \'elaborer des LPH uniformes. L'avantage retir\'e est de permettre l'\'elaboration d'une stra\'egie de placement de donn\'ees unidimensionnelles
%% %\footnote{Il n'est pas clair pour la r\'edactrice pourquoi les auteurs de MAAN n'utilisent pas une g\'en\'eralisation des LPH \`a des dimensions plus \'elev\'ees \cite{indyk97locality-preserving}\ldots} 
%% alliant \`a la fois les 
%% b\'en\'efices d'une fonction de hachage uniforme (r\'epartition de la charge en termes de stockage entre les n\oe uds) et les b\'en\'efices de la localit\'e (optimisation des requ\^etes par intervalles). 
%% Soit $h$ une LPH uniforme, le principe de la localisation dans l'overlay MAAN est le suivant.    
%% Pour une requ\^ete portant sur l'intervalle $[l,u]$, MAAN \cite{cai04maan} r\'e-utilise l'algorithme de routage de Chord \ref{chord} pour acheminer 
%% la-dite requ\^ete jusqu'au n\oe ud $n_l$ successeur de $h(l)$. 
%% $n_l$ retourne les solutions intersectant son domaine et celui de la requ\^ete, puis v\'erifie s'il est aussi le successeur de $h(u)$. 
%% Si tel est le cas, le processus de recherche prend fin. Sinon la requ\^ete est transmise au successeur imm\'ediat $n_i$ de $n_l$ pour une nouvelle
%% it\'eration de l'algorihme, jusqu'\`a ce que le n\oe ud $n_u$ successeur de $h(u)$ soit atteint. Le principe de la recherche 
%% est \'etendu aux requ\^etes $d$-dimensionnelles en g\'en\'erant une LPH pour chaque attribut et en superposant les DHT : 
%% d\'esormais, chaque n\oe ud supervise $d$ intervalles et maintient la connaissance de $d$ successeurs. %Les requ\^etes multidimensionnelles sont r\'esolues localement \`a un n\oe ud par d\'ecomposition en requ\^etes unidimensionnelles et intersection des solutions.  
%% Enfin, MAAN supporte les requ\^etes multidimensionnelles en ramenant leur r\'esolution \`a 
%% la r\'esolution de requ\^etes unidimensionnelles. Le principe de ce type d'approche (cf. Mercury \ref{mercury} aussi) 
%% est de d\'ecomposer les requ\^etes en sous-requ\^etes
%% unidimensionnelles et de maintenir une DHT s\'epar\'ee pour chaque dimension, d\'edi\'ee \`a la r\'esolution des sous-requ\^etes portant sur l'attribut correspondant. Les limitations de cette approche sont de n\'ecessiter la connaissance \emph{\emph{a priori}} de la distribution des donn\'ees requise, et la difficult\'e de passer \`a l'\'echelle en termes de dimensionnalit\'e \'etant donn\'e le recours \`a une DHT par dimension. 
%% Nous renvoyons le lecteur int\'eress\'e par MAAN et l'approche par LPH aux travaux de Gupta, Agrawal \emph{\emph{\emph{et al.}}} \cite{gupta03approximate}. 
%
%\paragraph{Utilisation de fonctions de r\'eduction de la dimensionnalit\'e : exemple de Squid} % Squid, SCRAP, andrzejak02scalable
%% Partant d'un espace de solutions multidimensionnel, l'approche adopt\'ee par Squid \cite{andrzejak02scalable} est de lui faire subir une transformation afin de se ramener au cas du routage
%% dans un espace de cl�s unidimensionnel : la dimension de cet espace est r\'eduite \`a $1$ gr\^ace \`a une courbe remplissante 
%% (ou de couverture ou de recouvrement) de l'espace (\emph{space-filling curves} ou SFC \cite{sagan94space}.
%% Une courbe remplissante de dimension $n$ est une application continue surjective de $[0,1]$ sur $[0,1]^n$. 
%% En particulier, une courbe remplissante de dimension 2 est une courbe continue traversant chaque point d'un carr\'e unti\'e $[0,1]^2$. Apr\`es application de la fonction, 
%% un point dans l'espace d'origine peut \^etre identifi\'e sur la courbe obtenue par la distance s\'eparant ce point et l'une des extr\'emit\'es de la courbe. 
%% Les SFC pr\'eservent la localit\'e des donn\'ees : deux images proches sur la courbe ont forc\'ement des ant\'ec\'ecents proches 
%% dans l'espace d'origine (en revanche, deux points proches dans l'espace d'origine n'ont pas forc\'ement des images proches sur la courbe). 
%% Les SFC offrent donc le double avantage par-rapport aux fonctions de hachage traditionnelles
%%  d'une gestion native des attributs multidimensionnels, \'evitant l'empilement de DHT d\'ecrit plus haut dans MAAN \ref{empilement}, et d'une
%% partition des donn\'ees pr\'eservant la localit\'e. 
%% % Une SFC est une application 
%% % continue depuis un espace un espace de dimensions $d$ dans un espace unidimensionnel $f: N^d\rightarrow N$. L'espace \`a $d$-dimensions est consid\'er\'e 
%% % comme un hypercube de dimension $d$ que l'on associe \`a une courbe continue entrant et sortant une seule fois du cube et traversant une fois et une seule 
%% % chaque point du cube.
%% La strat\'egie de routage choisie est d'attribuer des cl\'es g\'e\'er\'ees al\'eatoirement aux n\oe uds et de les connecter en une topologie de routage 
%% en anneau, \`a la Chord \ref{chord}. La strat\'egie de partitionnement comporte alors deux \'etapes : 
%% i) construction de la courbe de Hilbert associ\'ee \`a l'espace des donn\'ees d'origine (hypercube) ; 
%% ii) segmentation de la courbe obtenue et affectation d'un segment \`a chaque n\oe ud (un segment correspondant \`a un intervalle de valeurs cons\'ecutives dans le nouvel espace 
%% de solutions unidimensionnel).  
%% La r\'esolution d'une requ\^ete par intervalles multidimensionnelle se fait \'egalement en deux temps : i) identification des segments cons\'ecutifs 
%% (\emph{clusters}) parcourant la r\'egion de l'espace des solutions d\'elimit\'ee par la requ\^ete (cf. figure \ref{fig:squid requete}), 
%% ii) envoi de la requ\^ete aux n\oe uds responsables de ces clusters.   
%% 
%%  \begin{figure}[!h]
%%  \centering
%%  \includegraphics[width=0.4\textwidth]{./fig/squid1.png}
%%  % Skiplist.png: 399x88 pixel, 72dpi, 14.07x3.10 cm, bb=0 0 399 88
%%  \caption{R\'egions de l'espace des solutions correspondant aux requ\^etes par intervalles : $(000,*)$ et $(1*,0*)$}
%%  \label{fig:squid requete}
%% \end{figure}
%% 
%% A noter que Squid h\'erite des limitations de Chord \ref{chord}, notamment une sensibilit\'e des performances de routage \`a la distribution des donn\'ees.  
%% L'utilisation de SFC pr\'esente l'inconv\'enient que des donn\'ees contigues dans l'espace d'origine peuvent se retrouver \'eclat\'ees 
%% sur des segments non-cons\'ecutifs de la courbe, qui n\'ecessite d'\^etre requ\^et\'e s\'epar\'ement. 
%% Suivant la m\^eme approche, \cite{andrzejak02scalable} utilise aussi une courbe de Hilbert mais avec la topologie de pairs de CAN \ref{} (soit un tore muti-dimensionnel) ; 
%% SCRAP, propos\'e dans  \cite{ganesan04one}, utilise une courbe-Z pour le placement et un graphe \`a enjambements \ref{} pour le routage ; 
%
%
%% Plus g\'en\'eralement, cette famille de solutions bas\'ee DHT propose une approche par couches, une DHT servant d'infrastruture de routage 
%% sur laquelle sont empil\'es des m\'ecanismes (r\'epartition de 
%% charge, gestion de requ\^etes par intervalles, etc.). Cette approche par couches \`a une incidence sur les performances de ces syst\`emes.
%% %, en comparaison de solutions offrant un support natif aux requ\^etes par intervalles. 
%% Chawathe \emph{\emph{\emph{et al.}}} [chawathe05case] font une \'etude de performances sur des applications
%% en grandeur r\'eelle utilisant une courbe Z au-dessus de OpenDHT et rel\`event des temps de r\'eponse de 2 \`a 4 secondes par requ\^ete 
%% pour moins d'une trentaine de n\oe uds. 
%% Ainsi, les avantages des overlay bas\'es DHT dans la r\'esolution de requ\^etes exactes sont consid\'erablement r\'eduits s'agissant des requ\^etes
%% par intervalles. Lorsque les intervalles sont suffisamment ouverts ou grands, le co\^ut d'une recherche peut devenir 
%% lin\'eaire, faisant perdre le b\'en\'efice d'une recherche en temps logarithmique typiquement offert par le mod\`ele bas\'e DHT. 
%

%
%Plus g\'en\'eralement, cette famille de solutions bas\'ee DHT propose une approche par couches, une DHT servant d'infrastruture de routage 
%sur laquelle sont empil\'es des m\'ecanismes (r\'epartition de 
%charge, gestion de requ\^etes par intervalles, etc.). Cette approche par couches \`a une incidence sur les performances de ces syst\`emes.
%%, en comparaison de solutions offrant un support natif aux requ\^etes par intervalles. 
%Chawathe \emph{\emph{\emph{et al.}}} [chawathe05case] font une \'etude de performances sur des applications
%en grandeur r\'eelle utilisant une courbe Z au-dessus de OpenDHT et rel\`event des temps de r\'eponse de 2 \`a 4 secondes par requ\^ete 
%pour moins d'une trentaine de n\oe uds. 
%Ainsi, les avantages des overlay bas\'es DHT dans la r\'esolution de requ\^etes exactes sont consid\'erablement r\'eduits s'agissant des requ\^etes
%par intervalles. Lorsque les intervalles sont suffisamment ouverts ou grands, le co\^ut d'une recherche peut devenir 
%lin\'eaire, faisant perdre le b\'en\'efice d'une recherche en temps logarithmique typiquement offert par le mod\`ele bas\'e DHT. 
%
%En conclusion, le support natif des requ\^etes autres que exactes passe donc par des solutions non bas\'ees DHT. Pour une solution s\'emantiques structu\'ee, 
%l'objectif est double : i) une indexation sans hachage ; ii) la connexion des pairs en graphe et l'exploitation dans le routage des propri\'et\'es g\'eom\'etriques de ce graphe.
%La sous-section qui suit envisage les structures de graphes prototypiques : liste \`a enjambements, arbres, floating, tesselation de Vorono\"{\i} (en commen\c cant pas une solution ne reposant sur aucune structure de donn\'ee en particulier). 
%
%\subsubsection{Approche bas\'ee sur un placement des donn\'ees sur un : exemple de Mercury}\label{mercury}
%% %L'ensemble solution de la requ\^ete multidimensionnelle est ensuite calcul\'e au niveau du n\oe ud d'entr\'ee en effectuant l'intersection des r\'esultats des sous-requ\^etes retourn\'es par chaque DHT. Le routage des sous-requ\^etes
%% %Le routage de la requ\^ete est effectu\'e dans la DHT de l'attribut le plus discriminant, afin de minimiser le nombre de pairs \`a contacter et donc les co\^uts de communication aff\'erents. 
%% Dans le m\^eme esprit que MAAN \ref{maan}, Mercury \cite{bharambe04mercury} maintient non pas une mais plusieurs DHT, d\'enomm\'ees emph{attribute hub}, 
%% une par dimension orthogonale de l'espace des solutions. La strat\'egie de placement des solutions sur ces << hub >>
%% est simple : le domaine de d\'efinition de l'attribut concern\'e est d\'ecoup\'e en intervalles de valeurs cons\'ecutives et chaque intervalle affect\'e \`a un n\oe ud
%% du << hub >>. Un n\oe ud du << hub >> $H_a$ associ\'e \`a l'attribut $a$, fait correspondre \`a une valeur $v$ 
%% les donn\'es index\'ees v\'erifiant le pr\'edicat $(a=v)$. Les donn\'ees sont r\'epliqu\'ees sur tous les 
%% << hub >>. M\^eme si Mercury ne recourt pas au hachage, la similarit\'e avec une DHT est grande : g\'eom\'etrie des n\o euds en anneau, 
%% utilisation de liens longs pour optimiser le routage au sein des \emph{hubs}, etc. 
%% N'utilisant pas de fonction de hachage, la propri\'et\'e de distribution uniforme des donn\'ees sur les n\oe uds n'est plus v\'erifi\'ee. Les auteurs en profitent
%% pour introduire un m\'ecanisme de r\'epartition de charge entre les n\oe uds : la taille relative de l'intervalle de valeurs attribu\'e \`a chaque n\oe ud est calcul\'e 
%% en fonction de la popularit\'e de ces valeurs. Plus un n\oe ud re\c coit de requ\^etes et moins \'elev\'e est le nombre de valeurs qu'il lui est donn\'e \`a superviser.    
%% La strat\'egie de routage d'un << hub >> est celle d'une structure en anneau. Une requ\^ete multidimensionnelle est repr\'esent\'ee par une conjonction de pr\'edicats. 
%% Mercury s\'electionne un attribut $y$ parmi ceux
%% sur lesquels porte la requ\^ete et passe la requ\^ete au << hub >> $H_y$, ce qui permet de d\'eterminer l'ensemble des n\oe uds $E$ h\'ebergeant des 
%% donn\'ees candidates, c'est-\`a-dire satisfaisant au moins les conditions sur $y$. La requ\^ete est transmise \`a chaque n\oe ud de appartenant \`a $E$.
%% L'ensemble des solutions satisfaisant la requ\^ete est constitu\'e de l'ensemble des donn\'ees retourn\'ees par les n\oe uds de $E$. 
%% Une optimisation du routage est propos\'ee, qui est de choisir le << hub >> correspondant au \`a l'attribut le plus discriminant, 
%% ce qui permet de minimiser le nombre de pairs contact\'es et donc les co\^uts de communication aff\'erents. %, les auteurs soulignent que ce m\`ecanisme ne passe pas \`a l'\'echelle en termes de nombre dimensionnalit\'e. 
%% Toutefois cette strat\'egie suppose une connaissance \emph{\emph{a priori}} de la distribution des donn\'ees, pas toujours disponible.
%% 
%% Fond\'e sur la m\^eme approche, SONAR \cite{sch\"utt07structured} choisit une strat\'egie de placement "directe" des donn\'ees sur les 
%

%
%\subsubsection{Approche bas\'ee arbre}
%Avant de consid\'erer les solutions bas\'ees arbre multidimensionnelles, nous nous attardons sur quelques solutions unidimensionnelles 
%dans la mesure o\`u elles pr\'esentent des similitudes structurelles avec PBAM. Nous reviendrons sur ces similitudes lors de la pr\'esentation de notre solution \ref{}. 
%
%\paragraph{TODO Terminer / Uni-dimensionnel %BATON, vbi-tree, P-Grid, {liau04efficient}
%}
%
%P-Grid \cite{aberer03p-grid} distribue un arbre trie \cite{knuth98art}. 
%chaque n\oe ud de P-Grid correspond \`a une feuille de l'arbre et supervise les donn\'ees dont le pr\'efixe correspond au chemin du n\oe ud 
%(ou de la feuille) dans l'arbre. Pour assurer la connexit\'e de l'overlay et permettre
%le routage pr\'efixe, en consid\'erant des cl\'es \`a $m$ bits, chaque n\oe ud $n$ poss\`ede $m$ voisins, un voisin par bit et dont la cl\'e varie pour ce bit par-rapport \`a la cl\'e
%de $n$. 
%\begin{figure}[!h]
%\centering
%\includegraphics[width=0.8\textwidth]{./fig/p-grid.png}
%% p-grid.png: 498x162 pixel, 72dpi, 17.57x5.71 cm, bb=0 0 498 162
%\caption{Exemple de tables de routage P-Grid}
%\label{fig:p-grid}
%\end{figure}
%Bien que les auteurs ne donnent pas de d\'etails concernant la gestion des requ\^etes par intervalles, les m\'ecanismes de recherche exacte peuvent \^etre \'etendus pour 
%b\'en\'eficier de la propri\'et\'e de localit\'e, pr\'eserv\'ee par le syst\`eme. 
%
%\cite{liau04efficient} propose d'\'etendre un arbre avec des liens suppl\'ementaires (nous parlerions d'un graphe). Ainsi les n\oe ud connaissent non seulement
%leur parent et leurs fils mais aussi des "voisins" et des "fr\^eres" (\emph{siblings}), correspondant \`a des liens entre n\oe uds de l'arbre d'un m\^eme niveau.  
%
%Enfin dernier exemple, BATON \cite{jagadish05baton}, de Jagadish et al, exploite un arbre B \'equilibr\'e. Chaque n\oe ud de l'arbre est repr\'esent\'e par un pair et chaque 
%pair supervise un intervalle de valeurs de l'espace des cl\'es.  
%
%\begin{figure}[!h]
%\centering
%\includegraphics[width=0.8\textwidth]{./fig/baton_ang.png}
%\caption{Exemple de tables de routage BATON}
%\label{fig:baton}
%\end{figure}
%
%\paragraph{Multi-dimensionnel %SkipIndex (kd tree) | DR-tree (extension R tree) | vbi-tree
%}

%
%\subsubsection{Approche bas\'ee tesselation de Vorono\"{\i}% ->Voronet/Raynet, SWAM-V
%}
%% Explor\'ee dans plusieurs travaux 
%% [nahas01application, li03localized, banaei-kashani04swam, steiner05fully, simon05distributed, beaumont07voronet, dong-young07protocol]
%% 
%% La triangulation de Delaunay offre de s\'eduisantes propri\'et\'es
%% g\'eom\'etriques pour la construction d'un r\'eseau overlay. Partant de
%% donn\'ees repr\'esent\'ees dans un espace d'attributs inf\'erieur \`a trois
%% dimensions %($\mathbb{R} ^2$, $\mathbb{R} ^3$), 
%% le diagramme de Delaunay induit
%% permet de router simplement, de mani\`ere gloutonne, sur la base d'une
%% distance euclidienne. Tandis que sa duale, le diagramme de Vorono\"{\i},
%% permet un partitionnement (pavage) de l'espace des donn\'ees. Ainsi dans
%% [VoroNet], chaque cellule de Vorono\"{\i} correspond \`a une r\'egion de
%% l'espace des donn\'ees g\'er\'ee par un m\^eme n\oe ud (assimil\'e au centre de
%% la cellule appel\'e \textit{objet}). Lorsqu'un n\oe ud re\c{c}oit une
%% requ\^ete pour un point $P$ (qu'il ne g\`ere pas), il la retransmet au n\oe ud
%% parmi ses voisins qui minimise la distance euclidienne entre son objet et $P$.
%% La recherche se termine avec le n\oe ud dont $P$ est l'objet ou qui contient
%% $P$. Pour optimiser le routage, VoroNet est   petit-mondis\'e   par
%% l'augmentation de son diagramme de Delaunay avec un lien suppl\'ementaire long
%% par sommet [ET LES PROCHES VOISINS ?].
%% 
%% [SCHEMA voronoi :
%% http://interstices.info/jcms/c\_19164/la-geometrie-des-contacts-entre-biomolecule,
%% http://graal.ens-lyon.fr/ lmarchal/docs/slides\_VoroNet.pdf].
%% 
%% Un des avantages d'une topologie de Vorono\"{\i} est qu'elle permet la
%% d\'efinition de distances exotiques
%% [http://www-sop.inria.fr/geometrica/courses/slides/delaunay-generalisations-od.pdf].
%% Le principal d\'esavantage au regard des objectifs affich\'es par PosNet, est
%% qu'au-del\`a d'une dimension \'egale \`a 3, la complexit\'e de calcul d'un
%% diagramme de Vorono\"{\i} \'evolue exponentiellement en la dimension (en plus
%% d'\^etre sensible \`a la propagation d erreurs de calcul) [Jean-Daniel
%% Boissonnat et Mariette Yvinec. Algorithmic Geometry. Cambridge University
%% Press, 1998.]. Il en d\'ecoule pour un r\'eseau overlay bas\'e sur cette
%% g\'eom\'etrie un co\^ut de maintenance prohibitif. Ce constat a amen\'e les
%% auteurs de VoroNet [Olivier Beaumont, Anne-Marie Kermarrec, Loris Marchal,
%% Etienne Riviere: VoroNet: A scalable object network based on Voronoi
%% tessellations. IPDPS 2007: 1-10] \`a proposer une extension de leur mod\`ele,
%% nomm\'e [RayNet]. RayNet pallie cette limitation en approximant le diagramme
%% de Vorono\"{\i}, afin d'augmenter la dimensionnalit\'e tout en pr\'eservant
%% les capacit\'es de routage de mani\`ere probabiliste, avec un co\^ut de
%% maintenance de la structure raisonnable (\'evoluant lin\'eairement en la
%% dimension.
%
%% TRANSITION
%% On observe que les structures de donn\'ees des overlays P2P structur\'es/semi-structur\'es
%% traditionnels sont directement issues du champ des base de donn\'ees
%% ditribu\'ees (Structured P2P schemes are specific SDDS schemes [Litwin, A
%% Scalable Distributes Data Structure for P2P Environment]).
%
%\paragraph{Exemple d\'etaill\'e : Voronet/Raynet TODO}
%
%TRANSITION
%<Confronter les deux modeles selon axes expressivite/``exhausitivite'' ou completude> Relativement \`a nos objectifs, on peut synth\'etiser 
%les informations pr\'esent\'ees
%ci-dessus en les conforntant selon deux axes\ldots
%On voit que les objectifs de PosNet le positionne entre les deux familles structur\'e/non-structur\'e : 
%-> cote structure  : les garanties en termes de precision et recall
%-> cote non structure : la richesse du modele de donnees (multidimensionnel), exploitee par des requetes plus expressives, notamment dediees au requetes comparatives
%=> Choix du semi-structur\'e
%

%}
%\begin{itemize}
%\item Au-dessus de BATON (\ref{baton}) : iSky [chen08isky]
%\end{itemize}
%
%%\subsection{Exemples d'autres types de requ\^etes support\'ees par des overlays P2P  >> >> >> >> >> >> SUPPRIME (?)}
%
%%\subsubsection{Requ\^etes par similarit\'e (boule)% -> pSearch, batko04scalable
%%}
%% pSearch = CAN + IR 
%%Un exemple int\'eresssant est [pSearch] cumule deux
%%techniques de RI. Bri\`evement, pSearch est un index [bas\'e-DHT], se
%%pr\'evalant de recherches textuelles bas\'ees sur le contenu et la
%%s\'emantique des documents. Documents et requ\^etes sont repr\'esent\'es sous
%%forme de vecteurs de termes. Lors d'une recherche, l'ad\'equation entre un
%%vecteur-document et le vecteur-requ\^ete est d\'etermin\'e selon le cosinus de
%%l'angle form\'e entre les deux. 
%%% Concernant l'indexation des documents, les
%%% auteurs \'evaluent deux techniques issues de la RI : le mod\`ele
%%% vectoriel\textit{}et l'indexation s\'emantique latente (\textit{latent
%%% semantic indexing }ou\textit{}LSI). Dans le mod\`ele vectoriel, que l'on
%%% doit \`a Gerard Salton [Gerard Salton, A. Wong, and C.S. Yang, A Vector Space
%%% Model for Automatic Indexing, Commun. ACM, vol. 18 (11), 1975, p. 613-620]),
%%% pour chaque document dans un ensemble on calcule la fr\'equence d occurrence
%%% d'un terme. Les fr\'equences d'occurence pour chaque terme composent un
%%% vecteur pour chaque document. Dans la pratique, seuls sont retenus les termes
%%% les plus discriminants : on voudra \'eviter de garder les mots qui sont
%%% pr\'esents dans tous les documents ou m\^eme dans beaucoup plus de 10\% des
%%% documents. Par ailleurs, chaque terme retenu, ou composante du vecteur, se
%%% voit attribuer un poids. Celui-ci exprime, intuitivement, l'importance d'un
%%% terme dans un document selon deux facteurs : i) toutes choses \'etant
%%% \'egales, plus un terme est fr\'equent dans un document, plus le document est
%%% pertinent par rapport \`a ce terme ; ii) on doit attribuer plus d importance,
%%% dans la requ\^ete de l utilisateur, aux termes plus rares. Une faiblesse du
%%% mod\`ele vectoriel r\'eside dans l'absence de prise en compte de la
%%% s\'emantique des termes. La polys\'emie ou la synonymie entra\^{\i}ne ainsi de
%%% la redondance dans les matrices d'occurrences , nuisible tant pour la
%%% rapidit\'e de traitement que pour la pr\'ecision du syst\`eme. Pour palier
%%% cela, pSearch utilise la m\'ethode LSI, qui permet de simplifier la matrice d
%%% occurrences calcul\'ee par VSM gr\^ace \`a une d\'ecomposition en valeurs
%%% singuli\`eres. Intuitivement, il s'agit de "regrouper les mots" ayant le
%%% m\^eme "sens". Le r\'esultat obtenu est une matrice s\'emantique, de
%%% dimensionalit\'e r\'eduite par-rapport \`a la matrice d'origine. 
%%TODO : COMPLETER PARTIE P2P
%%
%%\subsubsection{Requ\^etes top-k TODO% -> travaux REZA
%%}
%%
%%\subsubsection{Requ\^etes kNN TODO} %-> SWAM
%%
%%\subsubsection{Requ\^etes de type SQL% -> PIER
%%}
%%
%%PIER : superposition d'un moteur SQL par-dessus un overlay structu\'e 
%%P2P Information Exchange \& Retrieval  , est un projet de moteur de
%%requ\^etes issu de l'Universit\'e de Berkeley. PIER se situe au confluent des
%%bases de donn\'ees et des syst\`emes pair-\`a-pair. Son ambition est de
%%permettre l'ex\'ecution distribu\'ee \`a tr\`es grande \'echelle de requ\^etes
%%de type relationnel. Son parti pris de favoriser le passage \`a l'\'echelle
%%Internet en \'echange d'un rel\^achement des propri\'et\'es transactionnelles
%%le rapproche de l'esprit des solutions P2P   pures  . Par ailleurs, son
%%mod\`ele de donn\'ees riche et l'\'etendue de sa gamme de requ\^etes
%%justifient que l'on examine plus en d\'etails ses contributions.
%%
%%Se d\'emarquant des solutions de bases de donn\'ees distribu\'ees
%%traditionnelles, peu scalables, PIER exploite les propri\'et\'es du P2P en
%%int\'egrant un moteur de requ\^etes SQL (limit\'e) et une DHT. Le moteur
%%d\'efini pour une requ\^ete un plan d ex\'ecution, c'est-\`a-dire la
%%d\'ecompose en sous-requ\^etes. Chaque sous-requ\^ete est ensuite
%%d\'el\'egu\'ee \`a un n\oe ud du syst\`eme. La DHT sert tout \`a la fois
%%d'infrastructure de communication entre les n\oe uds (pour le transport des
%%tuples), de m\'emoire distribu\'ee (pour le stockage de variables temporaires)
%%et d'index distribu\'e. Le sch\'ema de nommage permet de router dans l'espace
%%des tables ou dans l'espace des tuples d'une table.
%%
%%On retient de PIER que si le moteur de requ\^etes est ind\'ependant du
%%substrat P2P, les performances du syst\`eme, elles, en d\'ependent fortement.
%%En effet, le moteur de requ\^ete s'appuie sur les capacit\'es de l'index P2P.
%%Ainsi, l'ex\'ecution de requ\^etes de haut niveau sur la base des services de
%%bas niveau d'une DHT entra\^{\i}nent n\'ecessairement des recherches
%%exhaustives et des traitements suppl\'ementaires au niveau du moteur. C'est
%%pourquoi PIER se repose sur diff\'erents index P2P en fonction du type de
%%requ\^etes : un mod\`ele sans s\'emantique (DHT) r\'eserv\'e aux requ\^etes
%%exactes et un index avec s\'emantique (un trie par exemple) pour les
%%requ\^etes par plages de valeurs.
%%
%%Nulle doute qu'il serait int\'eressant d'envisager l'ajout de PosNet parmi les
%%index de PIER et d'analyser les cons\'equences sur les performances de ce
%%dernier de l'utilisation d'un overlay offrant un support natif \`a des
%%requ\^etes relationnelles.
%% 
%% \subsection{Sch\'ema \'ecapitulatif sur les overlays P2P TODO}
%% [TABLEAU : r\'ecapitualtif solutions pr\'esent\'ees / requ\^etes support\'ees]
%% %[INSERER sch\'ema r\'ecapitulatif des diff\'erents types de r\'eseaux
%%   P2P : s'inspirer de rangiroa.essi.fr/cours/systeme2/03-pair-a-pair.ppt en le
%%   modifant] \\
%




